Next.js and WordPress launch checks
Reviewing a headless Next.js and WordPress website before launch: page and deployment problems identified at the route level, corrections scoped against the affected page types, and the changed behaviour retested on the live site.
Client work. The client's name and dates are withheld, and I have not reproduced the original test records.
What they wanted
Published pages should show the intended content and the intended canonical URL. Missing pages should return the right error rather than a page that looks published. And what was approved should be what production actually serves.
What was wrong
A headless setup has three sources of truth that can disagree: the HTML the server returns, what the browser renders once JavaScript has run, and what the framework serves for a route nobody meant to create. Here they did disagree, and the preview and production environments behaved differently from each other.
What I did
I led the technical SEO and launch checks, worked out whether each problem came from the application, the CMS or the deployment, supplied findings somebody else could reproduce, and retested the changed site.
- Scoped page and response corrections against the affected page types rather than against individual URLs.
- Aligned canonicals and CMS links with the intended public addresses.
- Compared the preview, the immutable deployment and production before approving a change.
How I checked it
I repeated HTTP and browser checks across the affected page types: missing pages, canonicals, internal links and the URLs stored in the CMS. Production was retested once the implementation changes were available.
What it doesn't prove
This is a check-and-correction record. It does not report indexing, traffic, ranking or revenue growth.
Have a system like this?
Describe the workflow, the data or the system you need built. Scope and any quote are handled privately after the enquiry.
Published