Define the audit question and boundary
A useful technical SEO audit report is a decision document: what was observed, why it conflicts with the intended behavior, who will change it and what will demonstrate that the change worked. Start with the hostname, environment, collection time, URL source, crawling/rendering method and access limits. A sample of six URLs is not a complete-site census. State which templates, devices and authenticated areas were not examined.
The original examples here run on your own computer. The before and after paths coexist so the same test can be repeated without changing a production site. They illustrate HTTP behavior, HTML directives and handoff decisions. They do not emulate Googlebot, JavaScript rendering, field performance or an indexing pipeline. Relative canonicals keep the local exercise portable; production implementations should follow the canonical URL guidance.
Record evidence someone else can reproduce
Preserve the exact URL, method, response chain, relevant headers and source snippet. Add a UTC timestamp and a trace or screenshot reference when collecting real evidence. If a browser-rendered page differs from the initial response, record both views and the tool settings. Keep observation, explanation and recommendation in separate fields; “not checked” must remain different from “passed.”
In the local kit, run the verification command to obtain all six response pairs as JSON. Compare it with evidence.json from the ZIP. Server dates and ephemeral ports are deliberately omitted from the stable trace; the trace is a reproducible fixture, not a dated observation of a customer site. The commands are fixed examples, not an arbitrary-site crawler.
Prioritize intent, reach and confidence separately
The three high-priority examples contradict an explicit delivery or indexing intent. Two medium-priority examples need a narrower template/content correction. The control requires no change. These labels belong to this exercise. On a real site, record the affected population, business-critical paths, evidence confidence, change risk and effort before sequencing work. Six sample rows cannot establish site-wide prevalence.
Assign one accountable owner and a review date to each real finding. A large warning count does not outrank a proven failure on a critical path automatically. If the intended behavior is unknown, obtain that decision before altering noindex, redirects or canonicals. Never remove a deliberate exclusion solely to improve an audit score.
| ID | Observation | Priority | Owner |
|---|---|---|---|
| A01 | Public launch page carries noindex | High | Web developer |
| A02 | Robots prevents reading the exclusion directive | High | Platform owner |
| A03 | Permanent redirect ends in an error | High | Routing developer |
| A04 | Canonical points at unrelated content | Medium | SEO lead and developer |
| A05 | Missing page uses a success response | Medium | Web developer |
| A06 | Working control needs no speculative fix | No change | Audit reviewer |
Six findings with a developer handoff
A01 · Public launch page carries noindex
Observation: GET /launch returns 200 and a robots meta noindex. The stated intent is a public page eligible for search.
Why it matters: The directive contradicts that intent. Its presence is confirmed; Google having seen it is not.
Proposed action: Remove the unintended directive from the public template. Check response headers and rendered HTML as well as source HTML.
Owner: Web developer
Acceptance check: The replacement /fixed/launch returns 200 without noindex. Recheck the real deployment and use authorized URL Inspection separately.
A02 · Robots prevents reading the exclusion directive
Observation: robots.txt disallows /blocked/, while /blocked/page contains noindex. The stated intent is exclusion from search, not access restriction.
Why it matters: A compliant crawler cannot read the page directive at that path. Robots rules are not authentication.
Proposed action: Allow crawling of the intended excluded page while retaining noindex. Use authentication for genuinely private content.
Owner: Platform owner
Acceptance check: /fixed/blocked/page is outside the blocked prefix and still returns noindex. Validate the actual host rules and later indexing observations independently.
A03 · Permanent redirect ends in an error
Observation: /old-guide returns 301 to /missing-guide, which returns 404. The example assumes /guide is a relevant replacement.
Why it matters: The path fails to deliver the intended content. A redirect status does not prove a successful destination.
Proposed action: Point the moved URL directly to the relevant working replacement and update internal links. Do not redirect every removed page to the homepage.
Owner: Routing developer
Acceptance check: /fixed/old-guide returns one 301 followed by /guide with 200 and the expected content. Inspect the entire chain after deployment.
A04 · Canonical points at unrelated content
Observation: /variant declares /other-topic as canonical, although its content duplicates /guide.
Why it matters: The declared preference conflicts with the example content relationship. This does not reveal Google’s selected canonical.
Proposed action: Confirm equivalence, then align the canonical, internal links and sitemap with /guide. Retain distinct pages when their content serves different needs.
Owner: SEO lead and developer
Acceptance check: /fixed/variant declares /guide and that destination responds successfully. Check the Google-selected canonical separately when access is available.
A05 · Missing page uses a success response
Observation: /gone returns 200 with a Not found heading. There is no suitable replacement in this example.
Why it matters: This is an error-content/success-status mismatch and a soft-404 candidate, not an observed Google classification.
Proposed action: Return the appropriate missing-resource status and remove stale internal links. Keep a useful error page for visitors.
Owner: Web developer
Acceptance check: /fixed/gone returns 404 with the error content. A later Search Console observation is separate evidence, not part of this local test.
A06 · Working control needs no speculative fix
Observation: /guide returns 200, declares itself canonical and is not blocked by these robots rules. No noindex is present in this response.
Why it matters: These checks pass for this fixture. They do not prove content quality, rendered behavior, discovery, indexing or rankings.
Proposed action: Record a passing control. Investigate other signals only when the question and evidence justify it.
Owner: Audit reviewer
Acceptance check: The before and after responses remain identical. Preserve the passing evidence instead of manufacturing an issue to increase the issue count.
Close a finding with a fresh check
An implementation ticket is not closure evidence. Repeat the original request against the deployed environment, check representative sibling URLs and record the new timestamp and response. Preserve the old evidence alongside the new one. Mark technical acceptance separately from a later search-engine observation; a corrected directive is not a guarantee of indexing or traffic.
Use the report and action register
Download the filled CSV to inspect the six decisions, or use the header-only file for your own register. Add actual URLs, environment, UTC observation time, evidence references, reach, confidence, owner, due date, status and retest result. The HTML is a self-contained report for review or browser printing. These downloads are templates; this page does not save an account-level audit or inspect a supplied domain.
Begin the executive summary with the audit scope and the decisions needed, then show the priority queue, evidence, implementation dependencies and closure plan. Record deferred checks explicitly. Do not present this teaching sample as a client audit or replace unknown fields with invented measurements. A broader audit may require rendering, internationalization, structured data, accessibility and performance work beyond these six cases.
Keep technical checks separate from performance claims
Technical eligibility and observed search performance answer different questions. Use the ranking-report worksheet for dated query/page exports and the backlink audit for source-link findings. A functioning page may still be unindexed. A change in clicks does not identify a canonical fault, and a backlink order does not establish the cause of a ranking change.
SEO ranking report: compare visibility without confusing averages
How to do a backlink audit: evidence, priorities and an action template