Open the post in administration and copy its current published permalink. Compare that with the failing address. If the current URL works but an old shared URL fails, the main issue is compatibility for the old address. If the current URL also fails, investigate routing or content state.

Record the previous permalink structure and preserve existing redirect and rewrite configuration before editing it.

1. Confirm that the post or page is published and belongs to the intended installation.
2. Review Settings > Permalinks and verify the chosen structure.
3. Save the intended setting through WordPress to refresh supported rewrite rules, then read any configuration instructions it reports.
4. Check whether the server uses Apache-compatible rules or a different configuration such as NGINX.
5. Test several current URLs, including a category and paginated archive where relevant.

If the current published URL is https://example.com/services/, inspect its WordPress rewrite matches before replacing server rules. Run this from the verified installation using authorised WP-CLI access; it lists rules instead of refreshing or changing them.

wp --path='/home/ACCOUNT/sites/example.com' \
  --url='https://example.com' rewrite list \
  --match='https://example.com/services/' \
  --fields=match,query,source --format=table

A missing or conflicting application rule points toward the registered route or slug. A sensible WordPress match with a public 404 may instead require checking whether the web server forwards that request to WordPress at all. Compare with one working current permalink and preserve existing configuration before editing.

Expected result: The investigation distinguishes WordPress route registration from Apache, NGINX or proxy delivery. An old URL that has genuinely moved receives a deliberate redirect rather than an unrelated homepage fallback.

Create a meaningful old-to-new URL map for moved content and implement appropriate redirects through the supported tool. Do not send every missing URL to the homepage, which can conceal broken content relationships and confuse visitors.

Review internal links, menus, sitemaps and canonical metadata after a broad structure change. Updating the setting does not guarantee every hardcoded link inside content or external documents changes automatically.

Check for a slug collision, a plugin registering custom routes or a subdirectory installation whose server rules target the wrong path. A security or caching layer can also serve an old error response.

Avoid replacing the entire .htaccess file with a generic snippet without preserving security, application and hosting rules. On NGINX, editing an Apache file will not necessarily affect routing at all.

Test both new and important old URLs while signed out, and inspect the final destination and status. Check forms or integrations that use fixed paths.

If the change was accidental and widespread routing is broken, restore the recorded previous structure while investigating, keeping any new content in mind. Send support examples of a working and failing URL, the old and new structures and the server context. That evidence is more useful than repeatedly changing slugs or creating duplicate pages to replace content that already exists.

• Preserving redirects when replacing a WordPress website
• Designing a useful WordPress 404 template
• Planning a WordPress domain change
• Using WordPress recovery mode after a plugin error

• WordPress documentation
• WordPress developer documentation

• WP-CLI rewrite rule inspection