WordPress Homepage Works but Pages and Posts Return 404?

In this guide

If your WordPress homepage works but posts or pages return 404, first confirm that the exact published URL is correct, then check whether WordPress and the web server can route that URL. Saving the existing permalink settings can refresh rewrite rules. Changing the permalink structure is a different action and can create additional broken links.

A working homepage does not prove every route is healthy. The root address can be served successfully while requests for individual articles fail elsewhere. An owner report about shared post links describes this precise pattern, but the replies identify checks rather than a universal diagnosis.

Start with the URL your visitors actually use

Open the affected post in the dashboard and use its published View link. Compare that address with the link in your menu, newsletter or social post. Look for a changed slug, a missing directory, an old domain, unexpected punctuation or a copied preview URL. Confirm that the item is published and intended to be public.

Test the same address in a private browser window. If it works only while you are signed in, record that distinction. Private content, a cached public error or an access rule deserves a different investigation from a page that fails for everyone. Copy the complete failing address into your notes rather than describing it from memory.

Map the failure before changing anything

Choose a small set of representative URLs: one older post, one recent post, a normal page and the blog archive. Record which work, whether a redirect occurs and what the final address becomes. A failure confined to one post suggests a different scope from every address beneath a particular directory.

Notice whether the error page looks like your theme or a hosting provider’s response. That appearance is a clue, not proof of which component failed. A developer can inspect response headers, server logs and the route that handled the request. If the page itself loads but its images or styling fail, use the separate guide to missing WordPress assets.

Refresh the existing permalink rules carefully

Before a settings change, retain a current recovery point and note the permalink structure exactly as it stands. An authorized administrator can open Settings, then Permalinks, and save the existing selection without choosing another structure. Retest the original failing link immediately afterward.

WordPress explains the relationship between public addresses and permalink settings in its permalink documentation. Preserve those established addresses during a repair. Switching everything to a different format may make a test page accessible while leaving external links, bookmarks and indexed URLs broken.

If the save does not help, stop repeating it. Repeatedly saving the same settings provides little additional evidence. Record the result so the next person does not repeat the same experiment without checking the server.

Ask the host to inspect the route behind the URL

Server configuration belongs with the host or developer. They should establish which server handles the site, whether a reverse proxy sits in front of it, and which document root receives the failing request. A migration or domain change can leave the homepage and nested paths taking different routes.

On Apache, the investigation may include the relevant rewrite configuration and whether WordPress can maintain the required rules. On Nginx, an Apache configuration snippet is not a substitute for the correct server routing. The WordPress Nginx administration guide provides server-specific context. Configuration must match the actual hosting setup, including subdirectory installations and multisite where applicable.

Ask for a targeted explanation: which request failed, which rule handled it, and what changed. Avoid replacing entire configuration files with a generic internet example. Existing security, redirects and application-specific routes may depend on settings that example does not include.

Clear the error where it is being cached

After the underlying routing correction, a cached 404 can make the repair appear unsuccessful. Identify the page cache, host cache and CDN involved, then purge the affected addresses using supported controls. The guide to WordPress caching layers helps distinguish those stores.

Compare a fresh request with a repeat visit and check whether different hostnames behave consistently. Do not use a permanent cache bypass as the final solution. If the cache keeps storing an incorrect response, investigate why that response is being generated or why its cache rules are inappropriate.

Verify public links, not just the dashboard preview

Retest your sample URLs while signed out, including the exact originally shared link. Open internal navigation and pagination, then confirm that an intentionally nonexistent address still returns a proper 404. A repair should restore real pages without converting every invalid address into a homepage redirect.

Keep a short change record and monitor the affected routes after caches have been repopulated. If an established URL genuinely must change, plan its specific redirect separately. That is a URL migration decision, not a default permalink repair.

Frequently asked questions

Should I change all permalinks to fix a 404?

No. First save the existing structure and investigate routing. A new structure changes public addresses and can leave old links broken unless a separate redirect plan covers them.

Why does the homepage still work?

The root page and a nested content URL can follow different routing or caching paths. The homepage loading shows that part of the site responds, but it does not establish that post rewrites are correct.

Can a cache keep showing an error after a repair?

Yes. A stored error can survive the configuration change. Purge the relevant cache after the correction and verify fresh public requests rather than relying only on an administrator preview.

Prepared for website owners by Nithu / Suthakaran Nithursan. Dated problem examples link to their original reports and technical guidance. They are not Nithu client cases, proof of prevalence or guarantees.