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:
Minimize the chances of deploying code with detrimental SEO impact
Catch and correct errors that make their way into production early
Identify opportunities for future, related SEO enhancements
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.
QA Basics & Best Practices
At heart, the fundamentals of SEO QA success are the same as any QA:
Test in a staging environment before anything is pushed to production
Define a checklist of what’s important, including critical pages, user flows, conversion points, indexability, etc. (which can vary between channels and teams)
Evolve your QA checklist as you learn the ins and outs of your particular web stack, so no one makes the same mistake twice.
Refer to product requirements documentation to reference the anticipated technical risks
Find the right balance of time & effort that’s put into QA versus other work, which will vary from org to org
Automate the QA work that you can to reduce the organizational "costs" over time
Make tracking a point of focus, so no data is lost if GA or GTM tracking breaks
Use monitoring tools to quickly catch any issues that make their way through the cracks to production
Determining when to QA for your site
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.
Which SEO elements should be part of your QA checklist?
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.
Crawler Accessibility
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!)
SEO QA items for your checklist
robots.txt file - any new or removed disavowals that problematically impact whether search-engine bots can crawl the site and what they can crawl
Search-engine bots are blocked from crawling the site
Subfolders or URL parameters should or shouldn’t be blocked
Subfolders for images or resources (ex: JavaScript) are blocked
meta robots tags - unintended changes from index to noindex, follow to nofollow, and vice versa
canonical tags - check whether they were removed or changed to a new/incorrectly formatted URL
HTTP status codes - are pages serving 3{xx} (redirect), 4{xx} (not available), or 5{xx} (server) errors?
If you’re seeing 4{xx} errors, is it because URLs changed or redirects were stripped?
Link coding - links are properly coded via an <a href>, so search engines can read and follow them. (This is one of the more common JavaScript SEO encoding issues.)
Where things can get weird
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.
Content Changes
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.
SEO QA items for your checklist
Universal elements such as the navigation and footer links
Breadcrumbs
Titles
Meta Descriptions
On-page copy including headings
Links - ensure all internal and external links still appear, function, and haven’t changed
Structured data (since staging sites block crawlers, Google’s Schema Markup Testing Tool won’t work for staging URLs — so use a Chrome extension such as the SEO Pro Extension by Marketing Syrup)
The information in the markup can be found and parsed
Any information pulled into the structured data is correct
Information referenced in the structured data is also visible on the rendered page, as appropriate
Where things can get weird
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!)
Page Functionality: JavaScript & CSS
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)!
SEO QA items for your checklist
All of the page elements are present and functioning normally, especially JavaScript-dependent functionality such as navigation pop-outs, pagination, and filtering
No changes were made to the page experience that require a user interaction for content to appear, such as content that only loads when the user clicks or scrolls (Google cannot crawl this JS)
No problematic discrepancies exist between the HTML from the server response and the rendered HTML
Where things can get weird
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:
Meta robots
Canonicals
Titles
Meta descriptions
Page copy
Internal links
External links
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.
Mobile-Specific Issues
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!
Decorative image with the headline: "QA items for mobile web"
SEO QA items for your checklist
Parity with the desktop site and previous versions of your mobile site
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!
Broken or missing tracking
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!
SEO QA items for your checklist
Pre-launch staging QA: Analytics tracking code is available across pages or templates
Day-after-launch QA: Data is still flowing into your internal analytics platform and doesn’t show significant discrepancies with external tools such as GSC (there will usually be a bit of discrepancy between tools)
Where things can get weird
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.
Specific SEO QA scenarios
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-Specific QA
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.
SEO QA items for your checklist
Product reviews
Crawlable
Functioning/appears as expected
Flowing into structured data as expected (if applicable)
Product UGC
Crawlable
Functioning/appears as expected
Pagination still allows search engine crawlers to discover and follow internal links on indexable product listing pages (check that all of the links are in the HTML)
Facets and filters
Filtering is functioning correctly
Canonicalization is present and correct on filtered URLs
Indexation logic is still there: whether meta robots or URL-parameter disavowals in robots.txt
Search-engine crawlers can crawl page content (copy, links, etc.) on all indexable filtered URLs
A/B Testing QA
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.)
SEO QA items for your checklist
Search engine crawlers see the same elements across both pages, except for the variable
Refining your SEO QA over time
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.
Monitoring for issues that slip through
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.
Post-release crawl
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.
Automated crawling & monitoring
Most SEOs don’t have time to crawl the site once a week — that’s where automated crawling comes into play:
Google Search Console - Make sure your account is set up, notifications are coming through, and check for issues weekly.
Automated third-party crawling - If you have an SEO tool like Semrush, Ahrefs, or Moz, set up a weekly crawl that finds and categorizes issues for you.
Dedicated SEO monitoring toolsets - If you have the budget, tools like Content King provide real-time monitoring services. Rather than waiting a week to know what’s broken, you get immediate and automatic notifications.
Empower QA with an SEO mindset
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.
