In today’s agile development world, product and engineering squads efficiently squash bugs, roll out features, and push implementations across the line. This can fuel tremendous success for brands, but it also has the potential to cause unforeseen changes on a website.
Engineering teams generally implement a quality assurance process, and often a dedicated team, to ensure new rollouts don’t break the site experience.
It’s relatively rare for SEO to be a part of that picture (outside of channel-specific optimizations). Unfortunately, plenty of development work can have significant SEO implications.
Without SEO QA, things that break aren’t caught until there’s a visible hit to key business metrics like traffic and conversion. Plus, chances are, no one’s there to connect the dots between the work you’re launching today and related SEO opportunities you could maximize.
In an ideal process, SEOs have a chance to vet dev releases - and determine whether any software updates merit SEO-specific QA - before going to production. At the very least, SEO considerations should be a standardized piece of the QA testing puzzle.
This empowers the business to:
Below, we’ll guide you through the essentials of the process, including the critical elements for a complete SEO QA suite. Plus, we’ll share a free QA checklist template you can build on to bring your site’s documentation to life.
At heart, the fundamentals of SEO QA success are the same as any QA:
Your QA cadence should follow your site’s development release cycle, aligning with any existing QA processes for staging and live environments.
If the dev team is deploying code to the live site every two weeks, SEO quality assurance should also happen every two weeks.
Any major site change warrants consideration for QA work. The more custom software updates the development team releases, the more opportunities there are for something to break. Hence, a shorter development cycle and more frequent QA.
For sites where code releases are more seldom, such as WordPress- or Shopify-built sites - a monthly, quarterly, or - at minimum - yearly cadence may suffice.
Defining the specific SEO elements that merit QA creates a framework where minimal issues reach the light of production (aka, your live website).
When you write product requirements documentation for SEO-related dev work, you likely include key, relevant items to check in the acceptance criteria. Plus, you’re the key stakeholder, so the work comes to your desk for user acceptance testing.
That luxury doesn’t extend to every ticket. QAing non-SEO tickets you’re loosely familiar with - at best - calls for a more comprehensive checklist that covers all of your bases, even when the context is limited.
The most efficient way to do this is to break related items out into groups.
One of the most fundamental aspects of SEO is making sure that search engine crawlers can access URLs, crawl their contents, and use the information to surface pages in SERPs. Or to put it more simply, nothing is blocking them from crawling and indexing URLs.
It’s also an area of focus that tends to impact the site on a larger scale. Rules for crawlers can extend to several URLs at once, such as page templates that share the same meta robots tags, subfolders that are blocked by the robots.txt, etc.
That’s why we start here! (There’s nothing like an inopportune robots.txt change to take a lot of pages out of SEO circulation fast — and all the organic traffic that comes from them!)
Once upon a time, GSC notified us that Googlebot was blocked via a client’s robots.txt. Only, the file we could see didn’t match what GSC was seeing. It looked totally fine!
Turns out that three of the eight load-balancing servers (fancy DevOps/cloud-computing terms over here!) were using the staging instance of the robots.txt, but we only checked the one we could see. Googlebot checked them all and deindexed several pages (womp womp).
Once we uncovered the root of the indexing issue, we quickly resolved it. The moral of the story? Software is weird and complicated, and it sometimes breaks… in unexpected ways.
An SEO QA suite is a living document that you evolve and improve over time. It’s the place to document those weird, not-so-wonderful nooks and crannies of your website.
Whether it’s new, existing, or updated content, take a pass to validate that SEO elements such as on-page copy, media, metadata, and markup are all available and correct.
Even the most buttoned-up QA process is victim to unsuspected changes outside your control. Take it from a client brand who suddenly found that search engines could no longer crawl the links in their related products widget.
Why? The plugin updated its JS code, which rendered the links uncrawlable and removed all of that link equity flowing to critical product URLs.
This example marks the importance of regular monitoring and auditing. It’s where setting up an automated crawl in your third-party SEO tool plays a big role. (We’ll talk about this in a bit!)
One thing that can be tricky about JavaScript is that content served only in JS won’t show up in the HTML crawls that most crawling tools default to. If your site renders page content only in the browser itself - versus serving it in the initial HTML from the server response - be sure to enable JavaScript rendering in your crawl.
Looking solely at the pre-rendered HTML risks missing important elements that are changed in JavaScript. That’s pretty significant (and a pretty good reason to get in the habit of running regular JavaScript audits)!
The last item is particularly important because it’s where issues go unnoticed. JavaScript can change vital components of the page that aren’t easily visible without comparing the two sets of HTML, including:
One easy way to check for differences between pre-rendered and rendered HTML is the View Rendered Source extension for Chrome. It gives you a side-by-side comparison, highlighting any code that was added, changed, or removed.
Note: If you don’t see any HTML from the initial server response, it isn’t inherently an issue. It’s a bigger issue if you do have major page elements in the pre-rendered HTML and they’re markedly different in the rendered HTML, or if critical content isn’t available upon rendering.
Since most of us do our SEO work on a desktop, it’s easy to check for issues on the desktop version of a site and call it good. But we live in a mobile-first world — and just because it looks right on desktop, doesn’t mean the experience is the same on a smaller screen.
Remember, in the vast majority of cases, Google crawls mobile-first!
Can we share another tale of caution from our client case files?
In this case, GSC notified us that critical URLs were noindexed, but crawling the site normally we saw nothing wrong. By re-running the crawl as a mobile crawler, we discovered that only the mobile versions of pages were serving a meta robots noindex tag. Given that the website had just switched to mobile-first indexing, this was a big deal!
Tracking is one of the most important internal-facing elements of the business. It’s also one of the categories of QA that slips through the cracks more often than you’d think. When that happens, you won’t find the issues until the team sees a drop and temporary panic ensues. Plus, the longer it takes to fix, the more historical data missing from your tracking!
It's incredibly common for websites undergoing migrations - or even normal, ongoing updates - to simply "forget" to set up tracking. That could include neglecting to implement a Google Analytics tracking code altogether, not adding it to some specific pages or templates, or forgetting to set up event-, eCommerce-, or goal tracking.
If you see traffic drop off a cliff overnight, check Google Search Console first. The absence of a corresponding drop in GSC points to a tracking issue.
While the categories above cover the brunt of quality assurance for SEO, there are times when additional considerations come into play.
Your QA suite will include global site checks, checks for specific templates and critical pages, QA for redirects, SEO items specific to your industry, and more.
We’ll cover a couple of the major scenarios.
eCommerce sites have an additional layer to their site: software that allows them to sell and market goods to consumers. So if you’re an SEO working for an eCommerce brand, make the following a priority.
A/B testing on most sites isn’t driven by SEO, but it can sure have an impact on how search engines interact with your site. Not all SEO tools let you instruct crawlers to look at the control and the variant separately, so in most cases, crawlers are served either version of the page randomly.
That’s why parity is so important. Everything about the two pages should look the same to a crawler outside of the variable. If there are lots of variables, chances are it’s not the most telling test. (i.e. It’s near impossible to isolate which of the changes is driving the impact.)
The more you QA, the more you’ll draw connections between types of software updates and the way they might impact important SEO elements. Often, these connections are specific to your site, tech stack, plugins, etc.
The SEO QA checklist is a great place to document the patterns, connecting the dots for anyone who might perform SEO QA on the site — now or in the future. In turn, it will help you prioritize your QA, deprioritize some of the unrelated elements, and avoid repeating mistakes.
Making SEO QA an integral part of ongoing QA means fewer errors make it out into the world. But no QA process is 100% fail-safe. Issues will inevitably find a way into production.
The quicker those issues are found and resolved, the less likely they are to have a significant impact on the business-critical metrics in your measurement plan. Just as importantly, a longer timeline to a fix could mean a longer timeline to recovery once it’s implemented.
If you monitor metrics regularly but aren’t looking for issues consistently outside of QA, you’re going to find the issues in the numbers. Building in a monitoring process with SEO QA tools can catch things that break - before the numbers do too.
At the end of every release cycle, crawl the site to see whether any new issues appear. (Don’t forget to enable JavaScript rendering!) Our favorite tools for this are Screaming Frog or Sitebulb.
Most SEOs don’t have time to crawl the site once a week — that’s where automated crawling comes into play:
As an SEO, you’re the driving force weaving SEO best practices into the development lifecycle… and culture. That’s not just a matter of QAing on the backend, it’s also a product of setting your engineering and QA teams up for success.
Make sure SEO is always a consideration by documenting issues and showing the value of SEO in a way stakeholders can understand. (A good reason to adopt SEO business cases!) In turn, you’ll build a foundation of trust with Product Managers, which is the launching pad to an even better QA process.
Where can you review tickets or documentation before development to add critical acceptance criteria? Which resources will the Product & Engineering team find helpful in integrating SEO considerations into their work? These are the types of opportunities that power streamlined, effective, and integrated SEO QA.
It all begins with the QA suite you refine. We’re sending you off with a free on-page SEO QA example template, so you don’t have to build from scratch.
Home Search DataDigital Market IntelligenceOpinionated SEO Opinions Social Impact Careers Products Testimonials FeaturedIndustriesResourcesContact
