“I hate my developers,” “We deployed the wrong thing(s),” “Somebody put up a Disallow in my robots.txt that wasn’t meant to be there,” “The whole site is deindexed.” These are just some of the quotes that I’ve heard over the years on the relation between developers/engineers. Where usually, the developers are the ones that receive all the hate. It should stop. Usually, I try to reflect on what I would do in a situation like that. This often means that the SEO should have a little more reflection and figure out what they could have done to avoid a situation like that. In most cases, the answers that I get back are that they’re having a hard time working with their development team and don’t have a very good understanding of each other’s work.
How to work together & Creating a better understanding with developers
Speak their language, Learn their language, Use their tools/platforms, Ask for their input. Embrace their new technologies and ideas. Then, have a ton of fun!
- Github/JIRA/Confluence: How is work assigned to your development team, what tools do you use for this and do you leverage the tools that they like using or do you require them to be stuck in a tool that they don’t like. I’m quite confident that they rather use the tools that are already part of their regular development cycle.
- Retrospectives, Lunch & Learn: How often have you joined a retrospective of a development team or have been part of their lunch & learn. You don’t always have to know all the details about what they’ve worked on. But it for sure helps build up your own knowledge by learning more about their process/terminology and codebase/technology.
- Pull Requests: Have you ever gone through the code that was about to be merged into your codebase to see specifically what kind of changes your developer made. It will help you double check if this is what you meant and gives you a good understanding on where certain parts that matter for SEO live.
- Specs & Technical Requirements: Do you write your developers requirements, are you involved, have you ever read them to better understand what an integration takes? If you’ve always been used to rapid development on platform X doesn’t mean that platform Y is just as fast to have new implementations build for.
- Write requirements yourself or write a testing plan: An SEO feature didn’t turn out what you expected it to be? Well, did you actually exlain how it was supposed to work and wrote all the edge cases for it? Did you provide the specific for the texts that you wanted to show up. I bet you didn’t. So work with your product managers on writing requirements and help guide your QA engineers on how this could be tested. There should always be a way for you to test business logic in releases besides the functional/technical aspect of it.
- Embrace new technologies: Often developers have a better insight into what new technologies can help the platform that you work with. When I had no idea how a certain database + API could help us and started to get frustrated our engineering lead was happy to tell me that it would make rollouts of future landing pages way easier and avoided them having to use an old API that sometimes took days to deploy. Their efforts to implement this paid off big time already in the quarter after they had launched that (both in speed of the site and development time).
Educating Developers
Give your developers 1 fact a day about something relevant to them and SEO. Of course, you all care about certain topics already: user experience, speed, etc. But can you really expect them to know about canonical tags or the inner workings of HREF lang integrations? I’m convinced they shouldn’t know anything about that until they’ve met you. In the end, it’s not part of their education/learning curve, and it likely should never be there. On the other hand, if you guide your development team and tell them about why certain improvements need to happen, you’ll likely, over time, build up a valuable resource with your developers. Hopefully, in a way that they can actively contribute to your actual SEO strategy. That’s why I want to share two stories of how SEOs and Developers could also work together:
500 Server Request
A few years ago, when I worked internally with the TwitterCounter (RIP 🙁 ) team at The Next Web (one of their sister companies), the development team was planning to temporarily shut down the service for a few hours (2-6 hours depending on the progress). It was not great as a user experience, but it was inevitable as the servers were about to hit their limits and needed to be upgraded. Specifically for SEO, this meant that tens of millions of pages wouldn’t be accessible (including for crawlers) for the duration of the maintenance. Not great, but obviously, for SEO, you can take the right precautions. As our development had been sitting together with me for months (literally, they sat right next to me), I had the chance to slowly educate them on many SEO topics (including dealing with maintenance shutdowns). So when the time came to shut down the servers, the amazing question that came up was: “So, I imagine that we’ll put up a temporary 50X status code, so we will tell search engines that we are doing server maintenance).” I don’t think there was ever a better moment in time where developers stepped up with the right mindset and understanding about SEO.
Title experiments
At Postmates, we wanted to run experiments on title tags on different kinds of templates. As pages were crawled very frequently and there was enough traffic, it meant that we could run a few dozen experiments potentially yearly just on that. Which meant that it would be a lot of work every few weeks to create/update experiments. Instead, she approached us with the question if it was Ok to build a tiny CMS to run title experiments ourselves. A great case to show that it took a developer a few more days to build this on top of that but that it also provided us with the ability to work without her on this so we could leverage her (or others in our organization) for other (likely more high leverage) projects.
Velocity == Magic
Most developers are motivated by velocity, they want to see progress just as much as you want to. An easy way on how to achieve this is to break SEO workup. When you come in, I totally get it, you want XML sitemaps across different templates/sections, etc.. It’s not realistic to all put that work together as you just created a project yourself that will takes weeks to months to build. And there is no way that builds a business case and quickly your reputation is gone. Break up the work, start with an easy XML sitemap for a subsection. Show the value and expand from there: show them what an XML Sitemap Index looks like, have them add it to the robots.txt. Next: have them GZIP the files if they’re getting out of hand, after that you have a robust setup and meanwhile a bunch of releases that helped you get out the work.
Celebrating Success
Are you celebrating success with your development team? Have you shown them the results of their ideas and the work that they’ve done? How consistently do you share these learnings? For example, when? When we launched projects at Postmates, we went back to them regularly to show them how a canonical change or an additional category index page had helped our efforts to push another page. In the best cases, we could tell them how much additional revenue this had resulted in because we initiated either new pages or the updates were significant enough to measure impact.
TL;DR: I believe that developers and SEOs should work better together, and that mostly needs to come from the SEO side, so there is less hate on developers. Learn more about your development team’s procedure, work, codebase, programming language, and what they value in their work. That way, you can educate them on important SEO topics over time and celebrate success when you have successfully delivered a project or improvement.
What other ways do you see to improve the relationships between developers and SEO? Leave a tip in the comments.