A route inventory gives each important URL a job: its intended audience and purpose, canonical destination, indexation policy, and relationship to nearby pages. That makes redirect chains, duplicates, accidental noindex rules, and missing sitemap entries easier to reason about.
I review actual HTTP responses and rendered output for representative routes, including dynamic and missing-data cases. In Next.js, that can mean tracing a URL through layouts, route data, server and client boundaries, caching, and deployment behavior.
Route and template inventory
Status, redirect, robots, and canonical behavior
Crawlable internal paths and sitemap membership
Metadata and structured data should follow the content.
Titles, descriptions, canonical URLs, social metadata, and robots directives should describe the visible page and its intended state. For App Router sites, I inspect Metadata API and generateMetadata output across route types rather than assuming the source definition is the final response.
JSON-LD is useful when it accurately describes current, visible content. I check that it parses, matches its page, and follows the intended schema properties. Valid JSON or schema markup can improve machine understanding; neither guarantees a rich result or ranking.
Next.js Metadata API and dynamic metadata
Canonical and robots rules
Visible-content-aligned JSON-LD
Programmatic pages need a reason to exist.
A dataset row does not automatically deserve an indexable URL. I map page types to distinct user needs, inspect data coverage and provenance, and identify records or combinations that should be withheld, combined, or handled another way.
Then the route and template can have typed inputs, explicit missing-data behavior, duplicate checks, metadata and canonical rules, internal links, and sitemap controls. Editorial review stays in the loop: automated gates help catch predictable errors but do not decide whether a page is useful.
Intent-to-page mapping
Typed data and source provenance
Quality gates for duplicates, missing values, and releases
Measure the symptom, then keep watching.
Slow or unstable pages can involve server work, rendering boundaries, hydration, image and font discovery, JavaScript, CSS, or third-party scripts. I use a representative route and user journey to connect the visible symptom to a plausible implementation cause.
Lab traces help diagnose; field Core Web Vitals describe real-user experience when enough data exists. Search Console and analytics can inform post-release observation, with the limitations of delayed, sampled, or grouped reports made explicit.
LCP, INP, and CLS diagnosis
Lab measurements kept separate from field data
Release notes and follow-up checks
A way of working
Small enough to review. Complete enough to use.
01
Inventory
Choose routes, symptoms, and the evidence already available.
02
Trace
Follow the route through output, data, metadata, and deployment.
03
Prioritise
Separate confirmed defects, hypotheses, and dependencies.
04
Implement
Make the agreed code or configuration changes.
05
Verify
Recheck representative output and define post-release monitoring.
Depending on the agreed scope
What can leave the desk
Each engagement has a written boundary: the routes or features in scope, the access needed, what will be delivered, and what should happen next.
01
A route-level diagnosis with examples and supporting evidence
02
A prioritised implementation plan, or agreed code changes
03
Next.js metadata, rendering, canonical, sitemap, and schema checks as scoped
04
Programmatic page data contracts and release gates where needed
05
A validation record for representative routes and edge cases
06
A handover that separates implementation status from search outcomes
Selected implementations
A few things made for the web.
Client websites and independent products, with notes on the structure, interface, and implementation behind each one.
Project / 01
Brownsmith Dynamics
Service, product, guide, and article pages built as a navigable catalogue with related content paths.