Implementing SEO in a Development Environment

SEO is an interesting problem to solve in regards to product development and engineering. More so than other online marketing channels, SEO is heavily dependent on having access to the engineering queue. Without getting SEO tasks in the engineering queue, a lot of SEO becomes dead in the water. The inability to get into this queue is one reason SEO fails at many organizations.

It’s not uncommon for a consultant to produce an in-depth report, even with a prioritized list of changes, and see those changes never come to fruition. There are lots of reasons for this, but it often comes down to that task list never effectively making it into the active development queue. A whole post can be written on why this is, such as tasks not being clearly defined, or not generating enough top down buy in at the organization, but I want to talk about some tactics for improving the implementation of SEO tasks.

Top Down & Full Company Responsibility

One reason SEO fails in an organization is that the responsibility is often siloed into a team that doesn’t have full authority to effect change. Many organizations may have a setup that may look like this.

There is a clear divide between those executing SEO and social media, and those who hold the keys to effecting change on the website. The problem here is that this organization structure does not mirror how SEO actually happens.

SEO is an umbrella function that has many stakeholders, including marketing, social media, copy, product, PR, IT, operations, and engineering. When SEO is siloed as a marketing responsibility, it means the process for effecting change is difficult.

This often means the SEO has to take two approaches.

1. They have to execute as a bottom up activity, attempting to sneak changes in through project managers or engineering. This can be a function of favors and making friends. It works, but the speed of execution is slow.
2. The other approach is that SEO needs to continually make a business case to the gatekeepers over product / website. It’s a battle to have tasks entered into the queue each month or quarter. This battle includes stakeholders around the company who are also attempting to get access to limited resources.

The failure here happens when SEO cannot find a way to effectively get into this tasks list on a regular basis.

SEO is dependent on having access to the website to work as effectively. Without access, SEO cannot test tactics, be fast to market on changes in the industry, or use high-level strategic strategies to run the SEO marketing campaign.
One way to combat this is to, as an in-house SEO or consultant, create a culture and system that distributes success responsibility across the company. It can help to assign success responsibility to at least one person in each org that SEO happens. In addition, the SEO strategy should be defined as a top down function that has a strategy that is visible at the highest levels of the company.

Making SEO a Product Function

Another cultural change to consider is positioning SEO as not only a marketing function, but a product function. For many online businesses, the website is a product. Just as a software company will address bugs and functionality of their software on popular operating systems and browsers, an online company should address how their website (as a product) functions in popular search engines, since these systems are often the primary way users are accessing content on the internet.

With this view, many SEO tasks change from being marketing feature requests to product bugs. This change in view is slight, but important. It is important for the company to be aware if they’re executing product releases that have known bugs that prevent users from properly accessing information on the website. Items related to problems such as canonicalization, redirects, session ids, JavaScript, iframes, and flash are not feature requests, but bugs.

SEO should be tightly entrenched in all product related conversations.

Effectively Sizing Tasks

Many SEOs hand over tasks in a report with no effective listing of tasks. More sophisticated SEO consultants may create a tasks list. Even more sophisticated SEOs will prioritize this list.

One failure on part of many SEO consultants is not properly sizing the difficulty of tasks. The perception of difficulty is usually from their experience or what they’ve read.

This is limited because:

1. The side project work of many SEOs is usually on simplistic site setups
2. Doesn’t take into account legacy setups and limitations of a particular site’s development

A change that may appear simple on the surface, such as creating an XML sitemap, may be excessively complicated depending on historical data management.

Because of this, it’s valuable to build out a task list, pull in a developer familiar with the nuisances of the website and start bucketing tasks by difficulty. This could be a simple as writing out all tasks on post-it notes, writing out t-shirt size buckets on a whiteboard, and getting engineering to place tasks in their respective buckets.

This may highlight concerns that were not initially apparent, such as the database setup that makes querying for a dynamic sitemap.xml challenging, or that changing content on a product page may require the development of a new internal tool. Knowing this can help SEO make the right choices about where to spend resources, while also understanding the demands you’ll be placing on engineering with each request.

Effectively Prioritizing Tasks

After properly sizing a task, it becomes easier to effectively prioritize a task. The lessons learned in sizing a task may dramatically change your perception about a particular tactic. These tasks can be outlined with quadrant analysis that looks at difficulty versus value.

This view allows you to bucket tasks into a more effective priority system. The items that are high value and easy wins are the low hanging fruit and a high priority for development to pull from. These are the items that the development team can easily squeeze into the queue and execute on as development resources open up. The items in the bottom right quadrant are resource expensive, so their ROI may make them not be worth prioritizing immediately. That isn’t an argument against the value of doing them, but with limited resources, there are opportunity costs to all choices.

As time goes on, and internal structures improve, it is worth returning to your list of tasks and resizing, because a task that was at one time an XL task may have moved to a S task, which changes its priority.

Creating an SEO Pull System

Once these items have been properly sized and prioritized, you can create a task pull system that development can pull from to place into their TODO.

The SEO queue now becomes much more visible and priorities are highlighted. You can pull tasks in order of priority, while also knowing the engineering resources that task will demand.

Running in Parallel and Not Sequence

Effecting change usually comes down to a system that looks somewhat like this.

There are always a number of projects, tasks, and marketing ideas on the table that a company has to look at, make decisions on, and prioritize. Since resources are limited, and opportunity costs exist, this can become a difficult queue to get into. Getting into the queue is an entire post itself, but may include getting buy in from the c-suite, pulling enough data to demonstrate ROI, or creating an overall multi-disciplinary strategy that gets buy in across many stakeholders. That aside, there is a problem with this system in regards to SEO. The system is running entirely in sequence.

Getting into this list, or not, is the Achilles Heel of effecting change with on-site SEO. Every month an SEO task doesn’t get into this list is a month that SEO isn’t making incremental on-site progress.

One potential solution, which may not be right for all companies, is to create a set of development resources that are isolated away from the standard bucket of development resources. This side bucket would be dedicated to SEO and function outside of the standard queue. This would prevent a large company project from pulling enough resources to deem SEO dead in the water. This may come in the form of an SEO Developer, SEO Development team, or an isolated number of resource hours every month that nobody but SEO can touch.

This would allow development to be agile enough to ship sudden changes in SEO (canonical tag, schema, nofollow change, etc.), even if development is locked into a large company project.

Addressing Technical Debt

One major roadblock to SEO development is technical debt.

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

Developing without SEO implications in mind generates technical debt that will have to be paid down in order to execute SEO properly. Code may have been shipped that was not inherently flawed from a quick and dirty perspective (although that may in fact be the problem), but because SEO was not considered. Because of this, tasks that should be inherently simple are not. To execute a task, development may need to pay down on this debt first.

A change may mean that the company has to stop working on new projects and return to non-client facing code. This technical debt becomes a disincentive to work on a task. It’s important to consider this when approaching new SEO projects. Be prepared for the challenges this creates. It’s also creates an incentive to improve SEO education in the development department to slow the growth of SEO related technical debt. Lastly, it may also provide justification to set aside development resources for SEO, which can focus on addressing the technical debt without slowing down forward reaching projects.