A working homepage does not tell you much about a failing product page. The two requests may reach different content, routing rules or cached responses. Before saving permalink settings or adding redirects, collect a small set of addresses you can test again.
Start with the working homepage, one failing internal URL, and one other internal URL that still opens. Keep the language directory, spelling and trailing slash exactly as reported. Record when the problem started and any recent migration, slug change or deployment.
Check what the request actually returns
Open the failing address as a public visitor. Record the final URL, HTTP status and any redirects. A page displaying “not found” does not, by itself, establish that the response status is 404.
Then describe the scope. Does one old address fail, every product page fail, or only the English version fail? Those patterns suggest different next checks. They do not establish a cause on their own.
For a hypothetical comparison, one renamed campaign page might fail while current pages and archives still work. In that situation, checking the old link against the page's current permalink is a useful first step. It is not evidence that the whole site's routing needs replacing.
Confirm the content and its current address
Have someone with appropriate access check the original item in WordPress. Is it published? Is it private or still a draft? What permalink does the editor currently show?
An author preview is not a public availability test. Compare the published address with the actual link in the menu, email or advertisement that brought the visitor there. If a slug changed, preserve that history rather than creating a second copy of the page to make the old URL appear to work.
The WordPress permalink documentation explains the difference between query-based addresses and readable paths, and notes that readable permalinks depend on the server configuration. A technician can compare the real content ID with its readable URL, recording any redirect as well as the final response. An ID-based request that redirects is not an independent test of everything along the route.
Give the maintainer a comparison they can repeat
Use a short record rather than a list of changes already attempted:
| Address or check | What to record | What it helps distinguish |
|---|---|---|
| Working homepage | Final URL and status | One responding entry point |
| Failing internal page | Exact URL, status and redirect path | The reported failure |
| Another published internal page | Same observations | One item versus a wider pattern |
| Current editor permalink | Publication state and public URL | Missing content versus an outdated link |
| Other language, if applicable | Actual corresponding page and URL | Translation availability versus a shared path problem |
This is a blank investigation template, not a completed test or a customer incident. Do not put private preview links, credentials or unreviewed request logs into a public support discussion.
Make one justified change, then repeat the comparison
If failures began after a migration, ask the person responsible for hosting to compare the change record with the current route configuration. Record the existing permalink structure before an authorised adjustment. Changing that structure can change public URLs; a successful dashboard save is not proof that incoming requests now work.
If cached responses may be involved, compare the same address under documented conditions. Clearing a cache is an action to evaluate, not a diagnosis. After a correction, repeat the original failing request and sample the paths that worked before it. Include the other language where relevant.
Leave genuinely missing content missing
A deleted page without an equivalent replacement can correctly return 404. If content moved, consider a redirect to its relevant new destination. Sending every missing URL to the homepage can produce a soft 404 and confuse visitors, as Google's 404 guidance explains.
A useful error page can help a visitor navigate while keeping the appropriate response status. The aim is to restore the intended route or handle a missing item honestly, rather than make every address appear successful.
Adapted from WPShieldPro's guide to WordPress internal-page 404 errors. WPShieldPro is operated by Zhengzhou Wozhitao Technology Co., Ltd. and provides WordPress maintenance and technical support. This adaptation was prepared using AI; the existing concept illustrations are AI-assisted. The technical points were checked against the official documentation linked above. No customer case or completed test is claimed.
Top comments (0)