SEO QA Checklist: Verify the Fix Before Closing the Task
A practical acceptance checklist for SEO, development, and QA teams, with completed examples for title, canonical, and noindex fixes.
Checklist
SEO QA Checklist: Verify the Fix Before Closing the Task
A developer marks an SEO ticket complete. The code is deployed. Two weeks later, the SEO finds the old title on the live page, a canonical pointing to the wrong URL, or a noindex header nobody checked.
The missing step is acceptance. Someone must compare the production page with the requested state, record what they observed, and decide whether the task passes. Use this SEO QA checklist for that handoff. It is a focused check of a delivered change, not a fresh audit of the whole site.
TL;DR
- Define the requested live state before implementation starts.
- Keep "developer complete" and "SEO verified" as separate states.
- Check the production URL and the actual response or rendered page, as the change requires.
- Save the observed value, check date, verifier, and evidence with the task.
- Reopen failed work. Schedule a later check for changes that a release or template update could undo.
- Get the one-page SEO QA acceptance checklist for use in tickets and handoffs.
Write the acceptance test into the ticket
"Fix the canonical" leaves too much for the developer and reviewer to infer. Write the affected URL, current state, intended state, environment, and how the live result will be checked.
| Ticket field | Example |
|---|---|
| Affected URL | https://example.com/guides/site-migration/?ref=nav |
| Current state | Canonical points to the homepage |
| Requested state | Canonical points to https://example.com/guides/site-migration/ |
| Scope | Guide template and representative parameter variants |
| Acceptance check | Production HTML declares the intended canonical on the affected pages |
| Owners | Developer implements; SEO verifies; product owner approves any scope change |
That tells the developer what to ship and the SEO what to inspect. If the change is made in a shared template, list representative URLs. A single passing page cannot establish that every template variant is correct.
One-page SEO QA acceptance checklist
Use the full copyable checklist in your work queue. For each delivered change, record:
- Request: Exact URL or template, current state, expected state, risk, owner, and approver.
- Implementation: Deployment date, production environment, and ticket or release reference.
- Live response: Final URL, status code, redirect path if relevant, response headers, and page accessibility.
- Requested element: Actual production title, canonical, robots directive, link, content, or markup compared with the expected value.
- Scope sample: Other URLs affected by the same template, rule, or release.
- Verdict: Pass or fail, observed value, verifier, timestamp, and saved evidence.
- Follow-up: Search Console review or later recheck, with an owner and date.
Only run checks that fit the ticket. A title edit does not require a full JavaScript rendering audit. A change to a shared template may need one. If a check fails, preserve the observation and return the task to implementation instead of closing it with a note that it "looks wrong."
Example 1: Title change accepted on the live page
The team wants the service page's HTML title to describe its technical SEO offering. The content lead approves the wording. A developer publishes it through the CMS on September 14.
| Record | Filled example | |
|---|---|---|
| Task and URL | T-104 · https://example.com/services/seo/ | |
| Requested state | `<title>Technical SEO Services | Example</title>` |
| Implementer | Content developer; deployed September 14 | |
| Live check | SEO lead checked the production page September 15 at 10:00 UTC | |
| Observed state | HTTP 200; HTML <title> matches the approved text; page still has its intended self-canonical | |
| Evidence and verdict | Saved page response and ticket link; live QA passed | |
| Recheck | September 22, after the next service-page template release |
The acceptance test is the HTML title on the production URL. It is not the title link visible in one Google result. Google generates title links from several sources, so a different search result title does not prove that the team failed to deploy the requested <title>.
Example 2: Canonical declaration fixed, Google review pending
A guide's parameter URL declares the homepage as canonical. The developer updates the guide template to point variants to the clean guide URL.
| Record | Filled example |
|---|---|
| Task and URL | T-118 · https://example.com/guides/site-migration/?ref=nav |
| Requested state | Canonical points to https://example.com/guides/site-migration/ |
| Implementer | Web developer; deployed September 17 |
| Live check | SEO lead checked the parameter URL and clean URL September 18 at 14:00 UTC |
| Observed state | Both return HTTP 200; parameter page declares the clean URL; clean URL declares itself |
| Evidence and verdict | Saved live HTML for both URLs; implementation accepted |
| Recheck | Inspect the indexed version in Search Console after recrawling; owner: SEO lead |
This task passes its live acceptance test. Its later search outcome remains open. Google's canonical guidance treats a declared canonical as a signal, and the URL Inspection tool shows Google's selected canonical in indexed data. The live test cannot predict that selection. Keep the follow-up separate so the team does not call Google's decision "verified" on deployment day.
Example 3: Noindex removed from HTML, but the response still blocks indexing
A product page received an unintended noindex during a release. The developer removes the robots meta tag and marks the ticket complete on September 19. SEO QA checks the production response the next morning.
| Record | Filled example |
|---|---|
| Task and URL | T-131 · https://example.com/products/widget-pro/ |
| Requested state | No noindex in robots meta tags or X-Robots-Tag response headers; URL crawlable |
| First live check | September 20 at 09:00 UTC; meta tag gone, but response still sends X-Robots-Tag: noindex |
| First verdict | Failed; SEO lead reopened the task with the response header as evidence |
| Correction | Web developer removed the header rule September 20 |
| Second live check | September 21 at 09:00 UTC; HTTP 200, no noindex meta or header, robots.txt permits crawling |
| Final verdict | Live fix accepted; SEO lead owns a later Search Console indexing check and post-release recheck |
Google accepts noindex from either a robots meta tag or an HTTP response header. Removing one does not clear the other. Google also has to crawl the accessible page before its index reflects the change. A live pass means the production response is now correct; it does not promise immediate indexing.
Keep the state honest after the live check
For reporting, use states that describe what happened:
| State | Meaning |
|---|---|
| Requested | The expected result has been written and assigned |
| Implemented | The team says the change shipped |
| Live QA failed | The production result does not meet the acceptance test |
| Live QA passed | A named reviewer observed the expected production state |
| Search follow-up open | Google or performance evidence is still pending |
| Closed | Required live checks and assigned follow-ups are complete or explicitly tracked elsewhere |
Your workflow may use different labels. Preserve the distinction between someone finishing work and someone checking the result. My guide to building an SEO workflow covers how those handoffs fit into the wider project.
Recheck changes that can be undone
A successful check is a snapshot. A later template release, CMS edit, or configuration change can replace the correct value. Set a recheck for important URLs and record the previous and current states if something moves. The SEO change monitoring guide explains when manual checks, crawls, scripts, or scheduled monitoring fit that job.
In SEO Logbook, a URL-linked task can hold the expected result and owner. The team can use live verification, record the implemented change, and review later monitored changes on selected pages. Its help center describes the task and verification flow. Use your crawler, browser, response inspection, and Search Console for checks the monitor does not cover, including rendering and Google's later indexing decisions. Monitoring reports what it observes; it does not roll back a release or identify who made an unlogged external edit.
Close the ticket when the agreed live state has been observed and evidenced. Keep the search and regression checks visible until their own review dates.