The hardest problem in doing SEO isn’t the algorithm updates. It isn’t having access to the enterprise tools. It’s not even whether or not you have the experience to determine where to focus your efforts.
No, the hardest problem in SEO is getting developers to actually execute recommendations.
We all walk into projects hoping to discover an internal champion that can take the developers to lunch and buy them beers in hopes that our suggestions get turned into actions, but sometimes that champion doesn’t show up. In some cases, getting things done may require social engineering. In other cases, it just requires a degree in engineering.
Let’s talk about how you can be better prepared to get developers to act on your recommendations and drive some results.
The Anderson-Alderson scale of developers
First, let’s meet the players.
I like to think there are two opposite extremes in web developers, and I use two of my favorite characters to personify them. One is Thomas Anderson, whom you may remember from “The Matrix” before he became Neo.
Here’s how his boss describes him in the film: “You have a problem, Mr. Anderson. You think that you’re special. You believe that somehow the rules do not apply to you.”
Anderson developers are the type of employees who live on their own terms and only do things when they feel like it. They’re the mavericks that will argue with you on the merits of code style guides, why they left meta tags out of their custom-built CMS entirely, and why they will never implement AMP — meanwhile, not a single line of their code validates against the specifications they hold dear.
They’re also the developers who roll their eyes to your recommendations or talk about how they know all of the “SEO optimizations” you’re presenting, they just haven’t had the time to do them. Sure thing, Mr. Anderssssson.
On the other end of the spectrum you have Elliot Alderson.
For those of you who don’t watch “Mr. Robot,” Alderson is the type of person who will come into the office at 2:00 a.m. to fix things when they break, even going as far as to hop on the company jet that same night to dig into the network’s latest meltdown.
Alderson-type developers are itching to implement your recommendations right away. That’s not because they necessarily care about ranking, but because they care about being good at what they do.
This developer type is attentive and will call you out on your b.s. if you don’t know what you’re talking about. So don’t come in with recommendations about asynchronous JavaScript without understanding how it works.
Aldersons will also help you brainstorm the actual execution of a strong idea and how to help you get your recommendations prioritized in the black hole that is the dev queue. They’re likely to be aware of Google’s documentation, but recognize that it may not always be up to date and respect your experience, so they’ll ask for your thoughts before implementing something they’re unsure of.
My greatest experience with a developer on the Alderson end of the scale was on a client project for a television show. We’d flown out to LA to meet with the team and walk them through our SEO Site Audit.
While we were explaining some of those recommendations, the developer was sitting there in the room, not taking notes. Rather, this gentleman was committing code as we were explaining what needed to be fixed. By the time the meeting was over, all of our high-value recommendations had been implemented.
Unfortunately, I don’t remember that guy’s name — but he is a legend.
Strategic vs. execution deliverables
Throughout the course of my career, deliverables from many agencies have come across my desk, and I’m always struck by the way some companies present their recommendations.
Many deliverables are either just screen shots of Google tools or prescriptions with little to no context. I always like to imagine a CEO having someone print out our work to read while they are riding in a limo to the airport. I want that person to feel that they understand what we’re suggesting, why it’s important, and how we’re doing a great job.
Additionally, I often find that there is no supplemental document to the strategy document that helps the client and its development team actually execute on these recommendations. It’s very much presented as, “Here’s a problem, you should fix it. Good luck.”
For example, when we deliver an SEO Site Audit, each set of problems is presented with context as to why it matters, an illustration of the issue and a series of recommendations, both with screenshots and code snippets. Each set is then prioritized with a score of benefit, ease and readiness of implementation.
All of the issues are coded with a number so that they can be represented in a spreadsheet. In that spreadsheet, there is a tab for each coded issue that highlights the specific URLs where that issue is happening, as well as any corresponding data that represents that issue.
As an example, for a list of meta descriptions that are too long, we will include the those URLs, their meta descriptions and their length.
The bigger issue lies in deliverables that are presented more for the client’s review and approval than for implementation by developers. We have a deliverable called “Content Recommendations,” wherein we take a client’s content and place it into a model in Word and track changes to update the body copy, metadata and internal linking structure.
This is great for a marketer to review what we’re doing to their copy and make sure that we continue to maintain the voice and tone. It’s also great if the client has a marketing coordinator who will be doing the manual implementation.
It’s horrible from a development standpoint, in that it requires them to do a very tedious job of going page by page to copy and paste new items, and no developer wants to do that.
That means implementation of the recommendations in that Word document requires a developer who’s high on the Alderson side of the Anderson-Alderson scale.
On the other hand, if we review the client-facing version of the Content Recommendations document with the client and then place the resulting changes into a spreadsheet, a developer could write a script that goes through every page and makes the changes we’re suggesting. More on that later.
This would place the implementation closer to the Anderson end of the Anderson-Alderson scale.
Getting developers to do things is all about scale
Generally speaking, scale is always something to be mindful of with SEO recommendations. Sometimes, though, there is no way to scale what you’re trying to accomplish.
For instance, if you’ve migrated a site and changed its taxonomy in such a way that there is no definitive pattern, you cannot write rule-based .htaccess entries for its redirects.
Developers have a series of tools on their end that enforce changes and/or make things scale. It is our job to make our recommendations through this frame to get devs to actually implement them. Otherwise, the dev team will always find a way to push back.
Common SEO implementation tasks on the Anderson-Alderson scale
Certain SEO-specific tasks require more dev effort than others and rate differently on the Anderson-Alderson scale, where placement on that scale indicates what type of developer you need to be working with in order for those recommendations to be implemented. The following illustrates where these common tasks generally fall on that scale.
- Updating metadata. This process is typically quite tedious. Unless the copy is prepared where it’s easily extracted and placed into the page, it would require page-by-page updates in the CMS, or pulling from the document we prepare and placing it into the database.
- Updating body copy or embedded structured data. Similar to updating metadata, this is also quite tedious and requires page-by-page updates. In cases where we’re talking about updating schema.org code that’s integrated within the content rather than placed in the <head> using JSON-LD, this is a nightmare for a developer to implement.
- Updating internal linking structure. This could potentially be done programmatically, but only if the the relationships are effectively identified. In most cases, SEOs present the recommendation on a page-by-page level, and a developer cannot effectively scale that effort.
- Optimizing code for performance. Developers tend to be obsessed with speed, so much so that they shorten the word “performance” to “perf” so it can be said faster. However, they have an aversion to the critical rendering path recommendations that come out of the Google’s PageSpeed Insights. Of the SEO recommendations I make, these are the ones I tread the most lightly with because it’s an area in which developers are often defensive.Pro Tip: Use the DevTools Timeline and Network performance detail to get them on board with page speed optimizations. They tend to react better to those.
- Generating XML sitemaps following site taxonomy. There are many tools that support the development of XML sitemaps, but developers tend to just let those rip. This leads to XML sitemaps like “sitemap14.xml” rather than those that reflect meaningful segmentation following the site taxonomy and are therefore useful to SEOs for managing indexation.
- Generating HTML snapshots. Some JavaScript Single Page App frameworks such as Angular 1.x have historically had difficulty getting indexed. But developers have heard that Google is crawling using headless browsers, and they know that Angular is a framework developed by Google, so they sometimes are not compelled to account for its shortcomings.
- Implementing redirects. Redirects can be scaled pretty easily, as they are often done on the server configuration level and written through a series of pattern-matched rules. It’s extremely rare (in my experience) that a developer will not follow through on these.
- Fixing improper redirects. Conversely, when it comes to switching redirects from 302s to 301s, I have seen pushback from development teams. In fact, I was once told that the switch might break the site.
Pro Tip: Use the DevTools Timeline and Network performance detail to get them on board with page speed optimizations. They tend to react better to those.
Clearly, we need to seek out better developers to work with, or we have to find a way to make our recommendations Anderson-proof.
Allow me to introduce you to task runners
Web development, primarily on the front end, gets more and more complicated with each passing day. One of the more valuable concepts that have been introduced in the past five years is task runners.
Task runners such as Gulp and Grunt allow developers to automate a series of tasks every time they push new code. A more recent addition, Webpack, also features task-running capability. This is largely to keep developers out of doing mundane or tedious processes the machine itself can do, and many web projects are leveraging these for that purpose.
Without going into the specifics of the tools themselves, communities have grown around Grunt, Gulp and Webpack; as a result, a series of plugins is available. Of course, custom modules can be written for each, but the less work you create for developers, the better.
Going back to the idea of updating metadata at scale, there is a plugin for Grunt called grunt-meta-excel, which allows you to provide an XLSX file with changes to page titles, meta descriptions and open graph metadata.
Simply offering the file, developing a column mapping and running the task would then update all of the relevant pages on your site. Sure, what I’m suggesting applies more to flat files than content in a CMS, but of course there are task runners that run on the database level as well.
A developer could effectively modify this plugin to edit the database rather than editing files, or your Excel file could be converted to an SQL file quite quickly and run as an UPDATE across the database.
Finally, most modern content management systems have plugins or modules that allow developers to scale tedious tasks to similar effect. It’s up to you to do the research and know about them when preparing your recommendations.
Common SEO recommendations you can use task runners for
Grunt, Gulp and Webpack all have a series of plugins offering configurable functionality that allows a developer to quickly execute tedious SEO tasks. The following is a (non-exhaustive) list of SEO tasks and some plugins that can be used for them:
Code minification
Image compression
Automatic updates to XML sitemaps
AMP validation
AMP creation
Updating meta tags
Generating HTML snapshots
Page speed insights
Each of these plugins will allow you to prepare a specification (and, in some cases, support files). Then the developer simply has to configure the plugin to reflect it and run the tasks. You’ve effectively made their job quite easy by leveraging these tools.
Outside of the Grunt, Gulp, Webpack setups, a dev could use Webcheck to automate a series of other checks for several other SEO issues as highlighted in this StackOverflow thread. The idea is that the developer could write build tests that wouldn’t allow them to deploy the new site unless everything checked out. You can find more plugins by searching the npmjs.com.
Other ways to get developers to implement SEO recommendations
Task runners are certainly not an be-all-end-all; rather, they are another tool in the SEO’s toolbox for interfacing with developers effectively. There are many smaller touches that can help you get the development team to take action.
- Understand the tech stack, and frame your recommendations within it. Consider a scenario where you’ve suggested 301 redirects for your client. It turns out they are running Nginx instead of Apache. Do you know that Nginx does not employ an .htaccess file? If you don’t, you may suggest placing the 301 redirects there, and the developer may ignore everything else that you’re saying. Tools like BuiltWith.com will give you a general determination of what technologies are in use. A better idea is to look at the HTTP headers in Chrome DevTools.
No matter what you do, you should spend the time to get a detailed understanding of the tech stack when your engagement begins. - Give granular detail in your recommendations. If it requires the developer to look elsewhere outside of your document for the solution, you are far less likely to get them to implement the recommendation. Instead, explain the context and implementation in line within your deliverable rather than linking out to other people’s explanations. Although developers tend to never trust other people’s apps, some developers tend to respect your findings from DevTools more than many SEO tools. My guess is that this is due to the combination of granular detail and it being the tool they use every day.
- Give one solution, but know the other ones. Often an SEO issue can be solved a number of ways, and it can be hard to fight the desire to fill up your SEO documents by exhaustively highlighting all available options. Fight harder and only deliver one possible solution. Eliminating the need to make a decision will lead to developers being more likely to implement. However, if the development team shoots that one solution down, have another solution ready. For instance, if they can’t move the site from subdomains to subdirectories, then suggest a reverse proxy.
- Business cases and prioritization. This is perhaps the most valuable thing you can do to get buy-in up and down the organization, which leads to added pressure on the development team to get things done. Applying a dollar figure to the value of your implementations makes the idea of action more compelling. Prioritizing recommendations through this lens helps as well. Granted, we all know no one can truly predict the size of an opportunity, so do it with some sort of understandable methodology so you can get things to happen.
- Understand their development methodology. Whether it’s agile, waterfall, XP, some combination, or some new thing that only one team in the world does, look to understand it. Listen, I can’t stand when someone runs up on me at my desk while I’m in deep concentration to ask me a question they could have Googled. Similarly, developers hate when SEOs come to them and tell them they need to disrupt how they normally operate to accommodate an SEO recommendation. So if that team works in sprints, find out from their Scrum master when the sprint cycle ends and when the best time is to get your requirements into a subsequent sprint. You should also be working directly with this person to develop the recommendations into stories to place into their project management solution so the team can adhere to their standard workflow rather than needing to translate your work into how they operate.
- Develop a relationship with the development team. It seems obvious, but the soft skill of becoming friends with the development team will go a long way in their being more likely to work with you. In most cases, the relationship between SEO and technical teams is very transactional, so they only hear from you when you want something. Instead, if you take the time to have a genuine interest in these people, you’ll find they are just people trying to do the best they can, like you and me.
- Appeal to their self-interests. To the previous point, there are opportunities to align what you’re trying to do with what they are trying to do. For example, a recent client of ours had a development team looking to optimize page speed, but they were looking more closely at an internal metric rather than the external ones that Google is looking at. It was far easier getting buy-in on that subset of recommendations than any of the other ones because it supported the mandate that the person had been given by his bosses. So it was more valuable for me to focus in on that when speaking to him than on things like redirects. While that required some reprioritization of what I believed to be the most valuable tasks, it did help shift the focus on the page speed effort a bit to ensure that the items that I highlighted got prioritized. You lose some, you win some — as long as the outcome is income!
No matter what you do, you should spend the time to get a detailed understanding of the tech stack when your engagement begins.Do what you can to balance the scale
As a developer, I can tell you that even if you were to become one, it will always be difficult to get development teams to make things happen. However, when you speak their language and take more interest in bringing them the right detail-oriented solution, you will get a lot farther than those that do not.
Improving your deliverables, leveraging task runners, developing business cases, prioritizing effectively and taking a genuine interest in who you’re dealing with will get you much closer to complete implementation and better organic search performance. Best of luck converting your Andersons into Aldersons!
Some opinions expressed in this article may be those of a guest author and not necessarily Search Engine Land. Staff authors are listed here.
