SiteAuditLint SEO QA
What SEO QA covers
SEO QA, short for SEO quality assurance, is the process of testing SEO implementation before release and verifying it after deployment. It checks that a change did what it was supposed to do and nothing else.
SEO QA covers nine testing areas: status codes, crawl and index directives, canonicals, redirects, titles and headings, structured data, internal links, XML sitemaps and JavaScript rendering. Each area is tested in four release phases: define, test on staging, verify on production, and compare. The six guides in this section explain the methods. The checklists provide the lists to work through.
For the concepts behind each signal, see the Academy. For how SEO experiments and indexing tests work, see the SEO testing course.
Who it is for:
An audit describes a whole site at one moment and finds existing problems. SEO QA is tied to a specific change. It tests the change on staging, verifies it on production, and compares crawls so that only the differences the change caused need attention.
Why SEO QA matters
Most SEO losses after a release come from implementation, not strategy. A template drops its H1, a CDN rule adds noindex, a canonical reads the wrong environment variable, a redirect rule stacks on top of an older one. None of these are visible when you open the page in a browser, and all of them can affect thousands of URLs at once.
Search engines recrawl gradually, so a regression caught on release day usually affects only a small share of URLs. The same regression found weeks later, after rankings drop, has already been crawled across the site.
SEO QA workflow
Define, test, deploy, compare
The compare steps are what separate QA from auditing. Run a crawl before deployment, make the change, crawl again, and compare the results.
SEO QA guides
Each guide covers one testing method. Start with acceptance criteria if your team does not yet write SEO requirements into tickets.
Testing areas
Each area below explains what gets tested, why it tends to break during releases, what a typical regression looks like in a crawl comparison, and how to verify it.
Status Codes
What gets tested:
- Every indexable template returns 200
- Removed URLs return 301, 404 or 410 by plan, not by accident
- No new 5xx responses under production load
Why it breaks in releases: Routing changes, renamed slugs, middleware and failed data lookups all change status codes. Because routes are shared, one defect usually hits every URL of a template.
Typical regression:
How to verify: Diff the status field between the pre-release and post-release crawls, then group changed URLs by template.
Go deeper: Post-Deployment SEO Testing, Status codes lesson, HTTP 4xx issue.
How SiteAuditLint helps: Status changes appear in the comparison as a transition per URL, so 200 to 404 stands apart from long-standing errors.
Crawl and Index Directives
What gets tested:
- robots.txt rules unchanged unless ticketed
- No noindex in meta robots on indexable templates
- No noindex in the X-Robots-Tag header
Why it breaks in releases: Staging protections leak into production, CDN rules get broadened, and robots.txt prefixes match more than intended. Header directives are the hardest to spot because the page looks normal in a browser.
Typical regression:
How to verify: Prove staging blocks come from environment config before release, then compare directives and headers on production.
Go deeper: Pre-Deployment SEO Testing, HTTP Header SEO Testing, Indexability checklist.
How SiteAuditLint helps: Header values and meta robots are recorded per URL in every crawl, so a new noindex shows as a changed field rather than a buried warning.
Canonicals
What gets tested:
- One absolute canonical per indexable URL
- Canonical follows the rule for its template
- Target returns 200 and is indexable
- Value unchanged since the last crawl unless ticketed
Why it breaks in releases: Canonicals are built from base URL variables, route parameters and breadcrumb data. Refactors in any of those change canonicals silently.
Typical regression:
How to verify: Write the expected pattern per template, then diff the canonical field across crawls.
Go deeper: Canonical Testing, Canonicals lesson, Canonicalised URLs.
How SiteAuditLint helps: The canonical value is compared URL by URL, so a template-wide shift is visible in one list.
Redirects
What gets tested:
- Every mapped source reaches its destination in one hop
- Permanent moves use 301 or 308
- No loops, chains or homepage fallbacks
- Internal links point to final URLs
Why it breaks in releases: Redirects live in several layers at once: application, server and CDN. New rules interact with old ones and create chains that nobody wrote on purpose.
Typical regression:
How to verify: Validate the full redirect map with a result code per row, on staging and again on production.
Go deeper: Redirect Map Validation, Redirects lesson, Website migration SEO checklist.
How SiteAuditLint helps: Redirect chains, loops and internal links to redirects are reported per URL during the crawl.
Titles, Descriptions and Headings
What gets tested:
- One title and one description per URL, unique within the template
- Exactly one H1 per URL
- No fallback to template defaults
Why it breaks in releases: Template and component changes alter the head and heading structure. Missing CMS fields cause titles to fall back to site defaults across many pages at once.
Typical regression:
How to verify: Express each rule as an acceptance criterion with a pass and failure condition, then check it on staging and production.
Go deeper: SEO Acceptance Criteria, Title tags lesson, H1s lesson.
How SiteAuditLint helps: Title, description and H1 values are stored per crawl, so changes and reversions to defaults are listed alongside the URL.
Structured Data
What gets tested:
- Required schema type present on each template
- Markup parses and required properties exist
- Values match visible content
Why it breaks in releases: Structured data is often injected by a plugin or a single component. Removing or upgrading that component removes the markup everywhere.
Typical regression:
How to verify: Add schema presence and required properties to the template's acceptance criteria and compare presence between crawls.
Go deeper: Acceptance criteria library, Missing schema issue, Invalid schema issue.
How SiteAuditLint helps: Schema presence and validity are checked on every crawled URL, which makes a template-wide removal obvious in a comparison.
Internal Links
What gets tested:
- Navigation and footer links unchanged unless ticketed
- No links to 3xx, 4xx or 5xx URLs
- No internal nofollow introduced
- Key pages keep their inlinks
Why it breaks in releases: Navigation redesigns, component swaps and client-side menus remove links from the raw HTML. Pages that lose their links become hard to discover.
Typical regression:
How to verify: Compare inlink counts for priority URLs between crawls, and check links in raw HTML as well as rendered output.
Go deeper: Post-deployment triage, Internal link analysis, Orphan pages.
How SiteAuditLint helps: Inlinks and outlinks are recorded per URL, so lost links appear as a drop on the target page.
XML Sitemaps
What gets tested:
- Sitemap returns 200 and lists production URLs
- Only 200, indexable, canonical URLs listed
- Removed or redirected URLs dropped
Why it breaks in releases: Sitemaps are generated by jobs that run separately from the main release. They lag behind URL changes or list staging hosts after configuration changes.
Typical regression:
How to verify: Include the sitemap in the post-release smoke test and compare sitemap URLs against crawl status after every URL change.
Go deeper: Smoke test, XML sitemaps lesson, Sitemap non-200 issue.
How SiteAuditLint helps: Sitemap URLs are crawled and cross-checked with status and indexability, so non-200 and noindex entries are flagged.
JavaScript Rendering
What gets tested:
- Main content and links present in raw HTML
- Titles, canonicals and robots not changed by JavaScript
- Rendered and raw output agree
Why it breaks in releases: Framework upgrades and new client-side components move content and links out of the server response. Pages still look complete in a browser.
Typical regression:
How to verify: Crawl staging and production in both raw and rendered modes, and treat a gap between them as a failure.
Go deeper: Pre-Deployment SEO Testing, Rendering lesson, JavaScript SEO checklist.
How SiteAuditLint helps: Crawls can run with JavaScript rendering enabled, so raw and rendered results can be compared.
Release phases
| Phase | Goal | Evidence | Guide |
|---|---|---|---|
| Define | Turn SEO requirements into testable criteria | Criteria in the ticket | SEO Acceptance Criteria |
| Before deployment | Test the release candidate against production | Staging crawl and comparison, go or no-go decision | Pre-Deployment SEO Testing |
| After deployment | Confirm the live site behaves as tested | Smoke test, production crawl | Post-Deployment SEO Testing |
| Compare | Separate expected changes from regressions | Comparison with triage notes | Triage method |
Large URL changes add one more step: validating every row of the redirect map with Redirect Map Validation. For a full domain or platform move, use the website migration SEO checklist for the complete task list.
What a comparison shows
A comparison lines up two crawls URL by URL and field by field. Every difference falls into one of three groups.
| Classification | Meaning | Example | Action |
|---|---|---|---|
| Expected change | Listed in the release notes | Title rewrite on /pricing/ | Approve, update baseline |
| Regression | Not planned, moves a signal from correct to incorrect | noindex on all /guides/ URLs | Fix, roll back if severe |
| Needs review | Not planned, intent unclear | Footer link to /careers/ removed | Ask the ticket owner |
Indexable
Canonical A
H1 = 1
Noindex
Canonical B
H1 = 2
The field list for a comparison is in the SEO regression checklist.
SEO acceptance criteria
Developers can only test what is written down precisely. An SEO acceptance criterion names the requirement, the scope, the pass and failure conditions, and the evidence that closes the ticket.
QA test: Crawl product page templates.
Expected: 1 H1 per page.
Failure: 0 H1 or more than 1.
Verification: Production crawl after deployment.
The full method, with a library of criteria by template element, is in SEO Acceptance Criteria.
Common mistakes
Reviewing SEO after the code is merged
By the time a crawl finds the problem, the change is already in production. Put SEO acceptance criteria in the ticket so review happens before merge.
No written list of intended changes
Without release notes listing planned SEO changes, every difference in a comparison looks suspicious and real regressions get lost in the noise.
Treating a staging pass as done
CDN, firewall and production configuration only exist on the live site. Staging approval releases the build; production verification closes the ticket.
Testing popular URLs instead of templates
Defects are template-wide. One URL per template finds more problems than the ten most visited pages.
Checking the page in a browser
Headers, raw HTML and canonical values are invisible in a normal browser view. Test what crawlers receive, not what people see.
Fixing URLs one by one
When 300 URLs change the same way, the cause is one template or rule. Fix it at the source and re-crawl the template.
When to run SEO QA
- Every release that touches templates, routing, the head component or URLs
- Framework, CMS, theme or plugin upgrades
- CDN, cache, firewall or server configuration changes
- Redirect rule changes and URL restructures
- Feature flags that change rendered output
- On a schedule between releases, to catch drift from content and configuration edits
Where to go for what
Each topic has one home on SiteAuditLint. Use the page that matches the task.
| I want to | Go to |
|---|---|
| Understand an SEO concept | Academy |
| Learn how SEO experiments and indexing tests work | Academy: SEO testing |
| Work through release checks | SEO QA checklist |
| Compare crawls field by field | SEO regression checklist |
| Plan a migration | Website migration SEO checklist |
| Review every indexability signal | Indexability checklist |
| Write, test and verify an SEO change | The SEO QA guides on this page |
| See problems on real websites | Public SEO audits |
| Read news and analysis | Blog |
Frequently asked questions
What is SEO QA?
SEO QA, or SEO quality assurance, is the process of testing SEO implementation before a release and verifying it after deployment. It checks status codes, headers, crawl directives, canonicals, redirects, metadata, structured data and internal links against written requirements.
How is SEO QA different from an SEO audit?
An audit describes the state of a whole site at one moment and finds existing problems. SEO QA is tied to a specific change: it tests that change on staging, verifies it on production, and compares crawls to show what the change did.
Who is responsible for SEO QA?
SEO specialists write the requirements, developers build to them, and QA engineers or SEOs run the tests. On small teams one person often does all three, which is why written acceptance criteria and crawl comparisons matter.
How often should SEO QA run?
On every release that touches templates, routing, headers, redirects or the CMS, and on a recurring schedule between releases to catch drift from content edits and infrastructure changes.
Can SEO QA be automated?
Most of it can. Crawls on staging and production, crawl comparison, and scheduled audits handle detection. People still decide whether each change was intended, which is the triage step.
SiteAuditLint workflow
From release to verified change
Crawls run in the SiteAuditLint desktop crawler. Audit comparison diffs two crawls, scheduled audits and Slack alerts watch between releases, and Linear tickets send failures to developers. Agencies can see Pro vs Agency.