Check a WordPress 404 by recording the requested address, actual response status and whether the intended content still exists. Separate a missing page from a broken route or an outdated link. Choose a correction that matches the cause, then verify the response and destination from the visitor’s original starting point.
Begin with a reproducible example. Copy the complete address from the affected link and record when the problem was observed. Note whether the same content is available through another route. These observations give the page owner and hosting maintainer a shared question to investigate before either changes configuration.
Is the page missing, moved or failing to route?
Ask the content owner what should happen at the address. A deliberately retired page, a renamed service and a current page that suddenly fails need different decisions. Review the publication state and intended address alongside the original link, preserving the evidence of the failure.
Google’s HTTP-status guide explains the response layer. HTTP status codes are generated by the hosting server in response to a request. Inspect the actual status and redirect path as well as the visible page, because the wording displayed in a browser is only part of the result.
Google may consider content from a successful response for indexing. Google can report a soft 404 when successful-response content suggests an error. A page saying “not found” therefore needs a response check; changing its design or wording alone does not establish that its status matches the intended outcome.
Google Search removes previously indexed URLs returning 404 or 410 responses; this missing-content rule excludes 429. Google treats 429 as a server-overload signal. Decide whether the address should genuinely represent missing content before trying to remove the error. If the original answer still exists at another address, record the relevant destination and who approves the mapping.
Why does the hosting arrangement matter?
The WordPress Nginx guide covers one server arrangement. The WordPress Nginx guide covers Nginx acting as the primary standalone server. Identify the actual architecture before applying instructions, including whether another server or proxy participates in the request path.
In that arrangement, Nginx has no directory-level equivalent of Apache’s .htaccess file. That server configuration must be handled by an administrator. WordPress cannot automatically modify that Nginx server configuration. A suggested file edit needs to match the actual hosting arrangement and the administrator’s supported configuration process.
The guide notes that pretty-permalink behaviour differs on Nginx. If several current content routes fail together, give the maintainer representative examples and the time of any relevant change. Ask them to inspect the routing configuration that serves this site, rather than replacing a shared server configuration with a generic example.
Keep the scope of the investigation narrow and recoverable. Preserve the current site configuration before an approved change and record what will confirm the correction. If the host serves several sites, the verification should cover the intended site without casually changing unrelated service behaviour.
Which correction matches the evidence?
Use this original route-diagnosis worksheet to connect the observation with the responsible owner. Fill it in for the actual failure before choosing a redirect or hosting change.
| Observation | Question to investigate | Verification after correction |
|---|---|---|
| One old link fails | Has the content moved to a relevant address? | Original link reaches the approved answer |
| Current page exists but route fails | Is publication or routing inconsistent? | Intended public address returns the right content |
| Many content routes fail together | Which shared routing change applies? | Representative routes behave correctly |
| Page is deliberately retired | What should visitors see instead? | Missing-content response matches the decision |
| Error page returns success | Does response status match the displayed outcome? | Status and body describe the same result |
| Redirect reaches an irrelevant page | Was the destination chosen by reader purpose? | Destination answers the original need |
Google processes the final target’s content rather than the redirecting URL’s content. When a redirect is appropriate, inspect the final page and the path used to reach it. A working destination that answers a different question still needs an editorial decision.
Fix links you control when their destination has changed. Retain the old-address handling where it serves an approved purpose, but make the site’s own navigation point clearly to the intended current answer. Record the changed link and destination in the same investigation note.
Original moved-service diagnosis exercise
Consider a hypothetical service page renamed during a site update. An older advice article still links to its previous address. A visitor reports a not-found page, while the current service page is available through the navigation. Use an authorised test arrangement to investigate that specific path.
First, record the advice article’s link, the resulting status and the intended current service answer. Ask the content owner to confirm whether the new page is an appropriate replacement for the old one. Preserve the initial observation before implementing a link correction or mapped redirect.
Next, have the maintainer identify where the approved redirect belongs in this hosting arrangement. Apply the change through the supported process with a recoverable configuration record. Check the response from the old address, follow the destination and inspect whether the content matches the approved mapping.
Then update the advice article’s own link to the current destination. Test the journey from the published article and from the old bookmarked address separately. These checks establish different parts of the correction and should remain visible in the handover evidence.
Finally, test an unrelated existing page and an intentionally absent sample address. Record their responses to check that the scoped correction has not turned unrelated missing addresses into the same destination. If the results differ from the intended plan, preserve them for the next diagnosis rather than adding another broad rule.
How should recovery evidence be handed over?
Keep the original failing address, approved disposition, changed configuration and final observations together. Identify who owns the page content and who owns the routing arrangement. The next maintainer should be able to explain why the address redirects, remains available or returns a missing-content response.
Ask a colleague to repeat the original visitor journey using the handover record. Have them compare the visible answer with the recorded status and destination. Resolve any discrepancy before closing the investigation, and retain the recovery location with the configuration record for the authorised administrator.
Include the route’s future owner in that handover. If the service name changes again, they should know where its incoming links and mapped redirects are recorded. Review those entries together before another move, keeping the final destination clear and the reason for each address decision available to the next editor.
For related work, see hosting and website development. Get started with the affected addresses, expected destinations and any recent site changes.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.