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.
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.
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.
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.
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.
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.
Clearly, we need to seek out better developers to work with, or we have to find a way to make our recommendations Anderson-proof.
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.
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:
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.
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.
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!
The post How to get developers to implement SEO recommendations appeared first on Search Engine Land.