If the homepage works after a WordPress migration but every post returns 404, check the request-routing layer before recreating content. The database can contain the posts while the new web server fails to send their pretty URLs to WordPress.
This is different from intentionally changing URLs. Keep a migration redirect map for moved content, but do not redirect all failing URLs to the homepage to disguise a routing problem.
Establish one known-good content record
Choose a published post that existed before the move. Confirm its ID, status, slug, and expected public URL in the dashboard or with an authorized read-only WP-CLI lookup. A private or draft post is not a valid public routing control.
Compare the pretty URL with a query-style request such as https://example.com/?p=123, replacing the domain and ID. Record redirects as well as the final response. WordPress may redirect the query URL to the canonical pretty URL, so a final 404 does not automatically mean the query itself failed to reach WordPress.
Check whether the error page belongs to the host, proxy, or active theme. Appearance is a clue, not definitive proof; confirm with response headers and server logs for the same request.
Identify the actual web server
On Apache, .htaccess handling depends on the server configuration and permitted overrides. The Apache .htaccess documentation explains that directives can be ignored or rejected according to that configuration.
Nginx does not apply Apache .htaccess rules. A managed host may own routing outside the WordPress directory. Copying another site's .htaccess into either environment will not necessarily change request handling.
Ask the host which configuration serves the affected hostname and document root. Confirm the new deployment did not point traffic at a neighboring installation or an old directory.
Evidence guide for this investigation. Record your own observations; the fields are not test results.
Refresh the correct rules without erasing custom work
Back up the relevant configuration first. In a normal WordPress installation, saving Settings > Permalinks without changing the chosen structure can refresh WordPress rewrite rules. If WordPress cannot write the required server file, resolve that specific issue with the host rather than making the whole installation writable.
Preserve custom redirects, access restrictions, and host-managed sections. Do not replace the complete file with a generic single-site example when the site uses multisite, a subdirectory installation, or other custom routing. WordPress's rewrite reference distinguishes stored rules from a hard flush that updates server configuration.
For one custom post type failing while ordinary posts work, inspect its registration and rewrite slug. Repeatedly saving permalinks will not fix code that no longer registers the type. The custom post type planning guide explains that ownership boundary.
Verify a representative URL set
Test a post, page, category, paginated archive, custom record, and media file. Confirm intended redirects still preserve the destination and legitimate query parameters. Test an actually nonexistent URL too: it should remain a meaningful not-found response, not a successful homepage.
For a host-level mismatch, request routing and migration troubleshooting with the old URL, expected record, response trace, and server type. That evidence is more useful than another blanket redirect rule.
Sources checked September 30, 2026. Examples and visuals are explanatory, not customer measurements.