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.
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:
Comments