Published WordPress posts were returning 404 on a property website built with Next.js. The content existed in the CMS, but visitors following the affected URLs reached a missing-page response.

A separate problem affected nonexistent property URLs: they displayed a 404 interface while the server returned HTTP 200, indicating a successful response. The site needed to serve valid content correctly and return an appropriate response when a property genuinely did not exist.

I owned the technical diagnosis, correction requirements and independent release QA, working with the developer responsible for implementation.

I traced the published-post failure to the list of routes generated during the build. The generateStaticParams()query fetched only the first page of GraphQL results. Posts beyond that initial response were absent from the generated list.

With dynamicParams disabled for those routes, omitted posts returned 404 even though their WordPress records were valid and published. The problem was in how the frontend collected and handled the available content.

That diagnosis gave the developer a specific correction to make: fetch the complete paginated result set needed for route generation. The developer added pagination, and I checked the resulting deployment against the affected URLs.

The nonexistent-property issue required its own correction. A page looking like a 404 did not establish that the server was returning one.

The developer adjusted static-generation behavior for the property routes. I then checked that known-missing property URLs returned a genuine HTTP 404 while valid property pages continued to work. I kept this separate from the published-post pagination issue so that correcting one route type did not stand in for verifying the other.

I checked behavior across the deployment alias, the immutable deployment URL identifying the specific build, and the production domain. This tied each result to the version being reviewed and confirmed the public site after release.

Verification covered the response status, expected page title and the behavior of the selected valid and missing URLs. Both sides mattered: restoring published content would be incomplete if the same change caused nonexistent properties to appear successful.

The checked published-post URLs returned their expected pages, and the tested nonexistent property URLs returned HTTP 404. Valid property routes continued to operate.

The client received a clear diagnosis, targeted implementation requirements and independent confirmation of the deployed behavior. The work connected the CMS records, route-generation logic and public responses so the release could be assessed against specific, reproducible findings.

Related service: Fix broken URLs and missing pages after a migration.