Next.js gives developers tools for rendering pages and managing metadata, but a framework choice does not guarantee search rankings. A useful SEO implementation makes valuable pages discoverable, readable, and consistent across their content, URLs, and search signals. This checklist covers both the work to do and the evidence to collect before calling it complete.
Start with pages people need
Write down the searches each important page should satisfy. A service page should explain who the service is for, what the engagement includes, and what a visitor should do next. A technical article should resolve a specific question with enough detail to support a decision.
Give separate URLs to genuinely separate subjects. Avoid producing interchangeable pages for every variation of a phrase. If two proposed pages would answer the same question with the same evidence, combine them before building templates.
Treat content fields as part of the implementation. The CMS needs a title, summary, body, publication state, and stable slug. It also needs rules for what happens when an editor changes a slug or withdraws a page. These decisions are harder to repair after URLs have been shared.
Render the answer reliably
Choose a representative page from every template: homepage, service, article, listing, and detail page. Open each URL directly in a fresh browser session. Check that its primary content appears without a login, a location permission request, or a required click.
Google can render JavaScript, but relying on client-side fetching introduces more dependencies between a crawler request and the actual answer. Keep public headings, explanatory text, and important links in server-rendered or prerendered output where practical. Interactive controls can remain interactive without moving the whole page into an effect-driven loading flow.
Inspect the initial response and rendered DOM separately. Streaming can make them differ, so an incomplete first response is a reason to investigate the delivery sequence, not automatic proof that Google cannot index the page. The rendering guide explains that distinction.
Make metadata specific to the route
Use the App Router Metadata API rather than scattered manual tag injection. Next.js supports a static metadata export and a data-dependent generateMetadata function in Server Components. Dynamic route parameters in current examples are asynchronous, so older snippets that read params.slug synchronously need review.
Review the output, not only the source object. Every important page needs a descriptive title, a useful description, and the intended canonical URL. Check inherited title templates on nested routes. A template can accidentally append the company name twice or leave every detail page with its parent's title.
Open Graph information serves sharing previews. Test it as a sharing feature; a correct social card is not evidence that indexing or ranking is healthy. Keep image URLs absolute where the relevant metadata field requires them and verify that the deployed image can actually load.
Keep URL signals consistent
Choose a preferred hostname, HTTPS URL, and trailing-slash policy. Internal links, redirects, canonicals, and sitemap entries should agree with that choice. Google treats canonical annotations as signals, so conflicting signals create unnecessary ambiguity.
A filtered listing needs an explicit policy. A useful city landing page may deserve its own indexable URL, while arbitrary sort orders and tracking parameters usually do not need independent search entries. Do not canonicalize every distinct detail page to a generic parent merely because they share a layout.
Use real destination links for navigation. An anchor with an href exposes a URL directly; a card that navigates only through a click handler makes discovery less reliable. Test pagination and links beyond the first screen too.
Publish accurate discovery files
Generate app/sitemap.ts from the same publication rules that decide which pages exist. Include intended canonical URLs. Exclude drafts, redirects, and withdrawn content. Only change a last-modified value when the underlying page meaningfully changes.
Review app/robots.ts and the generated robots file on the production hostname. Keep staging controls separate from production configuration. A deployment can look complete while carrying a preview environment's crawl restrictions.
Robots rules and indexing directives have different jobs. A crawler blocked from fetching a page cannot inspect a noindex directive on that page. Review both controls together rather than using them interchangeably.
Add schema and performance checks
Describe visible content with relevant structured data. Validate representative pages and check for duplicate entities created by layouts, plugins, or CMS fields. The structured data guide covers implementation ownership and safe serialization.
Measure loading, responsiveness, and layout stability on realistic mobile conditions. A fast homepage cannot stand in for an article with a large image or a listing with expensive filters. Use Core Web Vitals diagnosis to connect a poor metric to the responsible request or interaction.
Run the release checklist
Record the URL, expected result, actual result, and owner for each check. A checked box without a tested URL is difficult to review later.
- Fetch an important public route directly and confirm a successful response with its intended content.
- Request an unknown slug and confirm genuine missing-page behavior rather than a success page containing an error message.
- Follow an old URL and verify that any permanent redirect reaches the relevant final destination without a loop.
- Inspect title, description, canonical, robots directives, and structured data in the deployed output.
- Crawl from navigation and content links, then investigate important URLs found only in the sitemap.
- Open the sitemap and robots file on production and compare their entries with the publication inventory.
- Test navigation, reading, and the primary enquiry action on a small screen and with a keyboard.
- Validate a representative URL in Google's inspection tools after launch and investigate discrepancies between intended and observed indexing.
Keep SEO checks in normal publishing work
Assign ownership for new pages, slug changes, expired offers, and schema changes. Add a release review when a shared layout, routing rule, or CMS query changes, since those changes can affect many pages at once.
Prioritize blockers first: inaccessible content, broken routes, accidental indexing restrictions, and conflicting URLs. Then improve page usefulness and performance with measurements that show what changed. If you need an implementation review, Apex's web team works on these foundations.