The first session in our initial three-part series SEO for Developers: Live with Search Engine Land we began covering Technical SEO and communicating issues between practitioners and developers. For a well-rounded conversation we hosted speakers with perspectives from both the practitioner side of things, as well as practical effectiveness with SEO In-House as part of an enterprise team. Our guests were:
The video is great if you’re looking to hear new ideas for effecting change with your clients, with developers, or wanting to be more effective from within your organization. Learn about team building tactics with developers in the mix as well as struggles you may face when you’re not part of an organization.
Communicating requirements of Technical SEO to developers
Depending on your situation, communicating SEO to developers can range from feeling like you’re always walking on eggshells and being very careful not to tread on ego or territory, to another extreme where you experience sheer frustration that however much you stress the importance of a needed change it seems hopeless, like as if you’re shouting into the void.
How can you best navigate personality problems? It’s not always going to be possible. There are things you can do to boost your odds of success, or otherwise avoid common pitfalls, and getting this information out to you was the goal of our discussion with the first part of our first session.
Anthony and Katie shared tales of how, starting with a grim outlook, they were able to ultimately succeed in partnership with developers, or just succeed anyway. You can hear how both pulled all the stops to try and be persuasive using everything from homemade cupcakes to bottles of vodka. While these are often cited as helpful tactics, in practice these ideas didn’t work for them.
Major site changes
During a major site change more than one aspect of a technology stack can change over a short period of time. When you have a correlating loss of traffic, you might associate a drop with the incident and a particular aspect of the technology at that point. That’s when Technical SEO skills and knowing the problem can come to a crossroads where you need to convey your findings to developers who might disagree with you about which path to take.
I did a forensic audit and found technical issues. The lead dev was like: “How do we know it’s not something else?” The answer is, you really don’t know. You just have a gut instinct and a lot of experience to be able to try and guide it in that way. We made the changes and right before the busiest time of year we saw a 40 point swing to the upside with millions in additional revenues. The GM had said: “I’m in awe. You know, this is great.” At that point the lead dev decided to re-platform to React.
There’s always a chance developers have a bias towards a technology that they’re comfortable with, or excited to be using. As developers, we like to think of ourselves as not holding an unwarranted bias for a technology, but in reality we want to control our own programming environment. We aren’t always able to and when we can we might a preference, same as anybody else.
Problems of a technology choice aren’t always developer-borne issues. In our third video, Martin Splitt spoke of developing a banking application with Angular. Angular, unfortunately, then became the anointed technology to use for everything. That was a mistake of leadership assuming a solid technology choice in one area of business is a safe bet everywhere else.
Things are never that easy.
The trouble with React is …
Whats more, the underlying technology stack powering React is not ideally suited for static websites even though it can certainly be used for them. For example, there’s Gatsby, a Static Site Generator (SSG) built on React and its conventions. Believe it or not plain old boring jQuery is still a far more appropriate choice for most static sites than Gatsby.
React is definitely an important innovation. When you need reactive page elements as part of site functionality, in other words, elements that change when universal or user specific data changes, that’s when React becomes an excellent choice! You get all the advantage of a paradigm shift from jQuery to a component-based reactive library for developing cutting-edge interactivity. For example: If you want roll your own chat, look into React.
A partial solution to the problem, known as Server-Side Rendering (SSR), is probably best described as a ‘hack’ bolted in place after feedback that early renditions of these libraries were not search engine friendly. Russ describes how React still tends to promote scaffolding or boilerplate that defaults to Client-Side Rendering (CSR) by convention. He shows us how to set yourself up for SEO with React and Vue.
A note about Evergreen Chromium
Evergreen Chromium keeps Googlebot up to date with the latest Chrome version. Google can now fetch CSR content fairly easily, but it’s certainly no silver bullet. Developers may think it means SSR is unnecessary, but for Googlebot your critical content is not immediately available and it may not be available at all without taking careful measures to ensure that it is.
It’s certainly not ideal for SEO, either. Even when you might fare a little better now with Google than in the past, you need to consider social media crawlers. Bing switched to Evergreen Chromium, but Facebook and Twitter haven’t done so yet and who knows if they ever will?
How about operationalizing SEO?
Working from within an organization, and with a sizable development team, Katie found that filing issues through the ticketing process wasn’t working fast enough for Technical SEO changes. Additionally, there was no way for her to gauge the relative importance of her SEO requests versus whatever else the development team was working on.
She was talking about operationalizing SEO and saying that anyone touching the website could be making multi-million dollar SEO decisions without realizing it. You’re always going to be outnumbered by people who are touching it. There’s never enough SEOs to have an SEO in the room for all these things. If you feel like you’re running around chasing fires all the time then you need to operationalize SEO.
Katie brought her developer teammates to more SMX session content where, once back at work, they began to ask her questions about how the changes they were thinking of might impact the website’s SEO. This was the very breakthrough she needed for going from being caught outside in a separate silo to working inside with the development team.
Since team building sessions fostered these more productive communications, Katie continued to organize Technical SEO trainings in-house and looks forward to a whole new build where SEO is a fundamental feature of the forthcoming new website.
The developers she worked with learned about using SEO tools and began using some of them directly in their workflow. They began testing development branch versions using command line SEO tools to make sure to realize good scores with Lighthouse and now Web Vitals. Any disagreements about SEO particulars would get resolved as it was typically just a matter of language that Katie’s team documentation helped clarify.
It was through these experiences that Katie was able to increase the priority of her Technical SEO with the development team whose members came to truly appreciate knowing the value of the business impact of what they were doing. This was a huge sea change shift going from not knowing whether her Technical SEO tickets were prioritized above a mystery plate of work tasks to developers caring about SEO every bit as much as they might frontend design details.
Server side rendering (SSR)
So, what happened to Anthony’s client when they switched to React before Googlebot’s Evergreen Chromium release? Just imagine when 80% of revenue was tied dollar-for-dollar to tanking rankings. Anthony tried everything to be persuasive, including bringing an outside developer in to recommend implementing SSR.
To satisfy SEO requirements, you’re going to need SSR strategies that ship code with fleshed-out and optimized content, or your rankings will not reflect the value of your website pages.
The lead developer was (rightly) disappointed to hear advice to implement SSR, negating all the practical advantage of using a reactive library in the first place. The unwarranted technology preference for React with a static site was suddenly a technology obstacle which began to haunt them as technical debt they didn’t want to pay down.
The lead developer insisted on delivering alternative explanations for what was happening and for an inexplicable reason fully resisted the recommendation to move to SSR. In the mean time, Google launched its Evergreen Chromium initiative and the new Googlebot indexing resulted in a 7% traffic lift which allowed the developer to further delay the inevitable.
It was not enough to recover lost revenues and it ultimately became increasingly clear React was a bad choice of technology for powering the static website. Anthony’s SSR recommendation was finally put in place and imagine what happened when search traffic quickly rose back up by 60%. Imagine the difference unearned revenue made for the time spent languishing with such a basic and obvious rendering issue.