An audit is an investigation. The fix is a deliverable.

On our Technical SEO page this is described as tickets with the fault, the evidence, the fix and the acceptance test. The point of that structure is that a developer can build it and someone else can tell whether it was built correctly. The SEO substance is in the acceptance test, and Google's documentation shows what a testable statement looks like for common changes.

Redirects are a good example. Google's redirects documentation says a permanent redirect (301 or 308) is a signal that the target should be canonical, while a temporary one is not. A ticket that only says "redirect the old page" leaves that open. One that names the status code, the single destination and the check to run does not. Google's site move guidance adds that redirects should avoid long chains, and that the URL Inspection tool or scripts can test them.

Hypothetical example of acceptance criteria: the old URL returns a 301 in one hop; the destination returns 200 with a self-referencing canonical; the URL Inspection live test shows the destination can be indexed. Each line is something a person can check against Google's own documentation.

Structured data and robots rules work the same way. Google says the Rich Results Test and URL Inspection catch most technical errors in markup, and that robots.txt must return a valid file or a 404 for crawling to continue normally.

We cover developer collaboration as part of our Technical SEO work. We write findings as specifications developers can build and test, and stay involved through QA.

• The fault: what is wrong, observable in a crawl, a log or a Search Console report.
• The evidence: what was seen, so the priority can be challenged.
• The fix: the specific change, precise enough to build.
• The acceptance test: how to confirm it worked.

Our site describes direct implementation as templates, redirects, structured data and tooling built by us where that's faster. For search, there is a practical reason these are the examples: each is a place where a small implementation detail changes what Google does.

Redirects are the clearest case. The status code decides whether Google treats the target as the canonical page. Google's documentation recommends server-side redirects where possible, and says JavaScript redirects should be used only when server-side or meta refresh redirects are not possible, because rendering can fail and Google may never see the redirect.

Structured data is another. Google's general guidelines say to put the markup on the page it describes, not to mark up content users cannot see, and not to block those pages from Googlebot with robots.txt or noindex. If duplicate pages exist, Google recommends the same structured data on all duplicates, not only the canonical page.

Templates matter for the same reason. Google says a canonical or hreflang annotation should point at the new URL after a move, and that internal links should be updated using the URL mapping. Those changes are most reliably made once, in the template or the redirect rules, rather than page by page.

Implementing directly also removes a hand-off. Where a recommendation needs developer capacity that does not exist, it can stay unbuilt. Our About page puts it plainly: a recommendation that nobody implements has achieved nothing, and we implement where required.

We cover direct implementation as part of Technical SEO. If a recommendation can go to your developers, it can, and we can work alongside them. If they have no capacity, we can make the changes. For the build side, see Ongoing development.

We describe this as releases checked before and after launch, so regressions are caught early. Google's site move guidance lists mistakes that stop a new site being fully indexed, and almost all of them are release faults: leftover noindex or robots.txt blocks, redirects that point at URLs that do not exist, a spike in crawl errors, too little server capacity, and sitemaps that still contain old URLs.

Before launch, the checks are the ones Google describes for preparation: what robots.txt will say once live, which noindex rules must be removed, whether deleted content returns a proper 404 or 410, and whether redirects behave. The URL Inspection live test shows whether a URL can be indexed and how Google renders it.

After launch, Google's Crawl Stats report shows response codes, response times and host status, including problems fetching robots.txt, which can slow or stop crawling. The URL Inspection tool reports Google's indexed version of a page, which is not a live test, so it can lag a release. Google advises using the Live Test for the current version.

Google also recommends keeping an eye on server logs after a launch, looking for Googlebot crawling and for URLs that unexpectedly return error status codes. A check that runs on both sides of a release is what turns a regression from a surprise in a traffic report into a ticket.

None of these tools guarantees an outcome. Google notes that "URL is on Google" means a page is eligible, not that it will appear.

We cover SEO QA as part of our Technical SEO work, and it is also part of Ongoing SEO. A related Insights article covers WordPress launch checks that protect rankings.