This educational example uses a fictional Australian home-services website built with Next.js. Every website URL uses the reserved example.com domain, and every finding is invented to demonstrate the structure of an audit register.
The example is not client data, not a completed SEO Guys audit, not a founder-reviewed deliverable and not evidence of a ranking result. It does not diagnose example.com or any real business.
A useful audit finding connects an observed symptom with a plausible consequence, priority, dependency, owner, acceptance test, live verification method, limitation and review condition. The downloadable CSV keeps those fields together so another person can inspect the decision.
Educational Next.js audit example
Inspect every evidence and decision field in one register
Use the six fictional example.com rows to understand the structure, then create a separate controlled register for verified website evidence.
Separate the demonstration from a real website audit
The example organisation, website behaviour, evidence and decisions are fictional. The rows use representative Next.js problems because template and metadata decisions can affect many routes, but they do not claim that every Next.js website has these faults.
A real audit needs permission, current access, dated evidence, representative URLs and people who understand the business purpose of each page. Copying a fictional priority into a live backlog without verifying the symptom can create new risk.
Use the example to assess the quality of a finding, not to produce an automated score. The priority is a decision that can change when scope, customer value, affected scale, confidence, implementation risk or dependencies change.
Write every finding so another person can challenge it
Evidence describes what was observed, where it was observed and how it can be reproduced. Consequence explains the customer or search risk without turning possibility into a guaranteed outcome.
Priority states the implementation order. Dependency records what must be known or completed first. Owner identifies the role able to act. Acceptance and live verification then define what done means before the status is closed.
Evidence and affected URL
Record the response, directive, rendered element, report example or template behaviour beside a reproducible representative URL.
Consequence and priority
Explain the plausible customer or search effect, then weigh value, scale, confidence and release risk.
Dependency and owner
Name the prerequisite decision and the role that can implement, approve or verify the change.
Acceptance and live verification
Define the expected behaviour and the repeatable production check that can prove whether the release meets it.
Limitation and review condition
State what the evidence cannot prove and the new evidence that would reopen, raise, lower or close the finding.
Review six fictional Next.js findings
The register contains six examples across crawl control, canonicals, internal links, sitemaps, metadata and performance evidence. The set deliberately includes urgent, planned and monitoring decisions rather than labelling every observation critical.
Each finding is a compact example. A real working record should also retain extraction dates, screenshots or response evidence, affected URL patterns, release references and approval history in the appropriate private system.
P0: EXAMPLE-AUDIT-001
The fictional production robots.txt response contains Disallow: /services/, while the audit scope marks service pages as intended public search destinations. Owner: Next.js developer. Acceptance: The production robots.txt response no longer blocks /services/, while preview and staging hosts remain protected by their own access controls.
P1: EXAMPLE-AUDIT-002
The rendered fictional service page declares https://www.example.com/ as its canonical URL because the root layout supplies one fixed canonical for every route. Owner: Next.js developer with SEO reviewer. Acceptance: The representative service page returns a single absolute self-referencing canonical, and each tested service route declares the intended canonical URL.
P1: EXAMPLE-AUDIT-003
The fictional Next.js homepage renders the service card as a div with a client-side click handler and no anchor element with an href in the rendered link path. Owner: Frontend developer. Acceptance: The rendered homepage contains a standard anchor with an href to the final service URL, keyboard activation works and the analytics event fires once.
P1: EXAMPLE-AUDIT-004
The fictional generated sitemap includes one redirected URL, one not-found URL and service URLs whose canonical points to the homepage. Owner: Next.js developer. Acceptance: Every sampled sitemap URL returns a successful response, is indexable, declares the intended canonical and is linked from the maintained site structure where appropriate.
P2: EXAMPLE-AUDIT-005
Three fictional service routes render the same generic title and description because the shared metadata function does not use route-specific service data. Owner: Content owner with Next.js developer. Acceptance: Each sampled service route has an accurate distinct title, description and visible main heading that agree on the page purpose without keyword repetition.
Monitor: EXAMPLE-AUDIT-006
A fictional laboratory test shows a large hero image delaying the main visible content, but the example has no representative field Core Web Vitals data. Owner: Frontend developer with analytics owner. Acceptance: The required image remains clear and correctly sized, the page reserves its layout space, the buying path still works and repeat laboratory tests improve without removing useful content or measurement.
Set priority after dependencies and release risk are visible
A crawl block on intended public service pages can precede metadata refinement because the pages first need a reliable crawl path. A sitemap cleanup depends on resolving the redirected, missing and canonical-conflicted URLs it currently lists.
Priority does not mean implementation difficulty alone. Consider the value of the affected pages, number of routes, confidence in the diagnosis, customer effect, reversibility and the risk of applying one template change across the site.
- Confirm the page or template is intended to be public and indexable.
- Separate one representative symptom from the full affected URL set.
- Record what must be decided or fixed before this item can start.
- Identify who implements, who approves and who verifies the release.
- Test a representative sample and important edge cases before a broad rollout.
- Document a rollback path for changes that can affect many routes.
Keep acceptance criteria separate from production verification
An acceptance test defines the expected behaviour before implementation. Live verification checks what customers and search systems can receive after deployment. Both are needed because a passing local or staging test does not prove the production release contains the change.
Verify the response, rendered page, internal path and important business action. Use Search Console as later search evidence where relevant, but do not keep an implementation task open solely because Google has not recrawled or selected the page yet.
- Record the release date and the production URL checked.
- Inspect the final response after redirects and edge delivery rules.
- Compare initial and rendered HTML for the expected search signals.
- Repeat navigation, form, analytics and accessibility checks affected by the change.
- Recrawl the representative set and preserve the verification output.
- Track later Search Console processing separately from release acceptance.
Use limitations and review conditions to prevent false certainty
A technical correction can make a page eligible, consistent or easier to discover. It cannot guarantee indexation, ranking, clicks or enquiries. Later movement can also reflect demand, competition, content, links, search systems and other changes.
A review condition makes the finding maintainable. It names the evidence that should reopen or change the decision, such as a template release, new route family, conflicting canonical, failed field data or repeated crawl error.
This resource is educational information, not legal advice, not a platform certification and not a ranking guarantee. A real audit should state its access limits and retain client evidence privately.
Download the fictional audit register
The CSV contains the six fictional rows and the complete decision fields. Keep the is_fictional column when using a row for training or demonstration so it cannot be mistaken for client evidence.
For a real project, create a new controlled register and replace every example value with dated evidence. Do not place credentials, personal information, private analytics or confidential client material in a public download.
- Preserve one stable ID for every finding.
- Use a representative URL and retain the wider affected pattern privately.
- Complete every decision field before implementation begins.
- Do not close a finding until the live verification is recorded.
- Retain resolved findings so later migrations can recover the decision history.
Sources and further reading
Primary and authoritative sources used to support the factual guidance in this resource.
- Source 01Google Search technical requirements, opens in a new tabGoogle's minimum crawl, response and indexable-content requirements, which establish eligibility rather than guaranteed indexing.
- Source 02Google canonical URL guidance, opens in a new tabOfficial guidance on redirects, canonical annotations, sitemaps and other canonical signals.
- Source 03Google crawlable link guidance, opens in a new tabOfficial guidance for links that Google can generally parse and for descriptive anchor text and context.
- Source 04Google sitemap guidance, opens in a new tabOfficial requirements and recommendations for maintaining and submitting XML sitemaps.
- Source 05Google title-link guidance, opens in a new tabOfficial guidance for descriptive titles, distinctive main headings and the signals used to generate title links.
- Source 06Google Core Web Vitals guidance, opens in a new tabOfficial context for Core Web Vitals, page experience and the need to consider relevant user evidence.