Check Next.js SEO route by route: confirm the useful content, the metadata produced for that route and the discovery paths leading to it. Tie all three to the same published record. Use the release worksheet below to examine dynamic pages, metadata rendering and sitemap output before treating a successful local page view as acceptance evidence.
Where should route metadata come from?
Choose a representative route and identify the record that supplies its visible heading, summary and publication state. Ask whether the metadata uses that same record and how missing data is handled. A page should not promise one subject in search while displaying another because its metadata and content follow different sources.
Next.js supports metadata object and generateMetadata exports only in Server Components. Documentation. Next.js can generate metadata from data using generateMetadata. Documentation. Use the documented APIs in the context of the application’s router and deployed framework version. Review where the metadata function obtains its data and what happens when the record is unavailable, unpublished or renamed. Include those conditions in the implementation brief rather than testing only an ideal published entry.
For fixed pages, define the approved metadata with the route. For record-driven pages, make the derivation understandable enough that an editor can predict the resulting title and description. Keep an explicit fallback decision for incomplete content instead of allowing the application name to become every page’s accidental title.
How does rendering affect a metadata inspection?
For dynamically rendered pages, Next.js can stream metadata after generateMetadata resolves. Documentation. Next.js disables metadata streaming for crawlers that expect metadata in the head. Documentation. Record the request context when collecting evidence. A browser inspection and a request made with a particular crawler user agent should be described precisely rather than combined into a generic statement that every visitor receives identical output.
Prerendered Next.js pages resolve metadata at build time rather than streaming it. Documentation. Include the rendering arrangement in the route’s release record. Ask the implementer to explain when the relevant record and metadata are evaluated and which event makes changed editorial content appear. Verify the actual deployed output after a content change using the application’s documented update process.
Keep useful page content in the acceptance exercise. Ask a reviewer to read the route’s direct response and rendered view, identify its main subject and find the next relevant navigation link. Metadata inspection should accompany that task, not replace checking the information the reader came to use.
An original route-to-record release worksheet
Use this practical checklist for a small set of representative routes. It connects editorial state to application output. Fill the evidence column with actual observations when the checks are performed; the prompts themselves are proposed checks.
| Route question | Evidence to collect | Decision before acceptance |
|---|---|---|
| Record identity | Route parameter and published record reference | Do heading and metadata describe the same record? |
| Data availability | Normal, missing and unpublished examples | Is each state handled intentionally? |
| Rendered response | Response content and request context | Can the useful content and metadata be located? |
| Metadata update | Observed output after a controlled edit | What makes the current version appear? |
| Discovery | Internal link and sitemap entry | Does each lead to the intended public route? |
| Share image | Resolved image for the route | Is the route-specific image the intended one? |
| Retirement | Renamed or withdrawn record example | Is the route’s subsequent treatment documented? |
Select examples from different route families, such as a fixed service page and a record-driven guide. Add an entry with incomplete optional metadata and one whose public status changes. Keep the expected behaviour next to each example so the reviewer can compare output with an intentional rule.
Retain the deployment reference and the content version used. If a later edit changes the evidence, create a new observation rather than silently rewriting the earlier record. This makes the distinction between a framework change and an editorial update visible during investigation.
How should the sitemap stay aligned with publication?
Next.js allows a static sitemap.xml in the root app directory. Documentation. Next.js can generate a sitemap from a default function returning URL entries. Documentation. Decide which records should contribute entries and which public URL each entry represents. Review the filtering rule against the same publication state used by the route. A development-only entry or an unpublished draft should be caught in the proposed comparison before release.
The Next.js sitemap route is cached by default unless a request-time API or dynamic option changes that behaviour. Documentation. Ask how the deployed sitemap becomes current when records change. Inspect the actual output after adding, renaming or withdrawing a representative record through the approved process. Retain the observation rather than assuming that a function reading the right data necessarily produced the expected public file at the relevant time.
Next.js documents splitting larger applications into multiple sitemaps. Documentation. If the application uses several sitemap files, include their discovery and representative entries in the worksheet. Keep splitting strategy separate from the editorial rule defining which URLs belong in search. The number of files is less useful than an understandable route-to-record relationship.
What should a route-specific share image show?
A more specific route-level Open Graph image takes precedence over an image higher in the structure. Documentation. Check the resolved image on a fixed page and a dynamic page, including a route with no dedicated image. Compare the result with the editorial intent and inspect the actual crop used for sharing. Keep the image’s relevance and provenance within the normal content-asset process.
A generated image can be tied to route data, but its rendered appearance still deserves inspection. Ask what happens with a long title, missing optional text or an unavailable image source. Include those conditions in the acceptance brief rather than letting a single attractive sample stand in for the whole feature.
Hypothetical example: an unpublished guide in the sitemap
Imagine a record-driven guide is withdrawn from public view, but a sitemap entry still points to its old route. This hypothetical case tests whether publication, routing and discovery follow the same rule.
Trace the record’s state through the route handler, metadata source and sitemap generation. Record the observed response at the old URL and the relevant sitemap output after the approved update procedure. Identify the mismatched rule before deciding which implementation change is needed.
Then rehearse a renamed published record. Confirm the intended new route and how the old reference is handled in the application’s agreed URL policy. Keep that policy with the canonicalisation guide rather than inventing a new rule for each edit.
For wider search requirements, see SEO. Use web development for the application brief and get started with representative routes, the content source and the publication changes you need to support.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.