404 error WordPress migration
Quickly diagnose the source of 404s after the switch
After a migration, a wave of URLs returning 404s is almost never a single issue. The most effective approach is to first identify the category of 404 you’re facing, since each cause requires a different fix. On WordPress, the most frequent sources are: permalinks that no longer match rewrite rules, lost redirects, a changed URL structure (with or without /category/, /blog/, language, etc.), moved media, or pages accidentally deleted during cleanup.
Start by observing the symptoms: do the 404s affect all pages or only certain types (posts, categories, tags, pages, WooCommerce products, images)? Do they occur only on the new server, only over HTTPS, or only behind a proxy/CDN? A global 404 often indicates broken rewriting (mod_rewrite, Nginx, permalink rules). Targeted 404s more likely point to slug changes, content not migrated, or missing redirects.
Distinguish a WordPress 404 from a server 404
On a migrated site, you must distinguish a 404 generated by WordPress (theme displaying the site’s 404 page) from a 404 returned directly by the web server (generic Apache/Nginx 404 page). The former often means WordPress is reachable but cannot find the requested resource (wrong URL, missing content). The latter can indicate incorrect server configuration, wrong domain mapping, or routing rules preventing WordPress from receiving the request.
Fix the most common cause: permalinks and rewrite rules
In many migrations, simply re-saving permalinks fixes some errors. This regenerates the rewrite rules and realigns WordPress with the server. If you moved from Apache to Nginx, from one host to another, or if a caching/optimization plugin was replaced, the rules may no longer be applied correctly.
Also check that the permalink structure on the new site matches the old one (for example /%postname%/ vs /tegory%/%postname%/. The slightest change creates different URLs and therefore 404s for old external links, bookmarks, and pages indexed by Google.
Apache case: the .htaccess did not follow or is no longer being read
If you are on Apache, a migration may have moved or overwritten the .htaccess file, or the server may not allow it to be read (wrong AllowOverride configuration). In that case, WordPress cannot apply rewrite rules: many pretty URLs return 404, while parameterized URLs may work. Checking the .htaccess and Apache configuration is then a priority.
Nginx case: rules to recreate on the server side
On Nginx, WordPress does not rely on .htaccess: an equivalent configuration is needed in the server block. During a migration, a minimal vhost may lack directives to route all requests to index.php. Result: pages, categories and posts return 404. Make sure the standard WordPress rules are present, and that the site root and the path to PHP-FPM are correct.
Discover our offers for WordPress website maintenance
Lost redirects: the classic migration issue
If the old site used redirects (redirect plugin, rules in .htaccess, Nginx configuration, or redirects managed by a CDN), they are often forgotten during the transfer. Yet they are essential to: preserve SEO, avoid a poor user experience, and guide bots to the new URLs.
First reconstruct the most critical redirects: those related to a structural change (e.g., moving from \/blog\/ to the root), a language or subfolder change, a slug change, or the removal of strategic pages. A 301 redirect is generally appropriate when the content still exists elsewhere. A 410 can be useful if the content is permanently deleted (and it is preferable to indicate that clearly).
Prioritize redirects: start with what receives traffic
Do not try to fix everything randomly by hand. Rely on the URLs that generate the most access (server logs, analytics, Search Console). Then address the most important pages: category pages, offer pages, product pages, top articles, pages with backlinks. This immediately reduces SEO impact and visitor frustration.
Unmigrated or poorly imported content: check data integrity
A migration can partially fail: posts in draft, missing pages, taxonomies not imported, missing media, or internal links not updated. Some migration tools filter content (by size, by role, by status), or do not correctly export custom fields (ACF), WooCommerce content, or URLs generated by a builder (Elementor, WPBakery, etc.).
To validate integrity, compare simple indicators between the old and the new site: number of pages, posts, categories, tags, products, media. If you spot a discrepancy, you have a serious lead. An incomplete import can explain 404s targeted at particular content types.
Slugs, accents, and transliteration rules
Watch out for slugs: if the previous instance used a different generation rule (accents preserved vs replaced, special characters, underscores, etc.), URLs may differ. A theme change, SEO plugin, or WordPress setting can alter behavior. One solution is to align slugs (when possible) or implement systematic redirects for the most common variants.
Media 404s: images, PDFs and static files after migration
404 errors don’t only affect HTML pages: they can hit images, PDFs, scripts and stylesheets. After migration, media can be missing if the folder uploads was not transferred, if permissions are incorrect, or if paths have changed (old domain still present in the database, different subfolder, or use of external storage).
In WordPress, media is often stored under /wp-content/uploads/year/month/. If you see 404s on those paths, check: the actual presence of the files on the server, access rights, and the existence of any blocking security rule (overly strict hotlink protection, web application firewall, etc.).
HTTPS, mixed content and implicit rewrites
A migration to HTTPS can cause URL rewrites and inconsistencies. Even if the browser reports mixed content rather than a 404, a proxy or plugin can force a non-existent URL version. Ensure the site address is consistent everywhere (WordPress, database, server config, CDN), and that old URLs are properly redirected.
Taxonomies and archives: 404 on categories, tags, authors
It happens that after migration, archive pages return 404: categories, tags, monthly archives, authors. This can be related to a change in the category base (e.g. removal of /category/), an SEO plugin that modified the structure, or the deactivation of the author page for privacy/SEO reasons.
Also check the robots.txt file, search engine visibility settings, and security plugins: some block endpoints or archives considered sensitive. If you disable archives, do it cleanly (redirects) rather than leaving 404s, especially if they were indexed.
Plugins, theme and builder: when migration breaks routing
Some themes and plugins add rewrite rules (custom post types, endpoints, virtual pages). If you migrate a site without reinstalling the same configuration (same theme version, same plugins, same modules enabled), you can generate 404s on entire sections: portfolio, events, knowledge base, account pages, etc.
Environments also differ: PHP version, server modules, memory limits. A plugin may fail to activate properly, or a feature may be silently disabled, resulting in missing routes. Reactivate components progressively, and check permalinks after each major change.
Discover our offers for WordPress website maintenance
The choice of theme matters more than you might think: some premium solutions include very specific content types and templates, whereas a custom theme can better isolate logic and limit surprises during a transfer. To explore impacts on structure and scalability, see Custom Theme vs Premium Theme.
Check errors in the right place: logs, SEO tools and crawl
To fix things effectively, you need a reliable list of error URLs. Combine multiple sources: server logs (to see all 404 requests), SEO crawling reports, and data from search engines (detected missing pages). The value of logs is that they also show bots, broken external links, and requests to static files.
When you run a crawl, segment by type: pages, posts, images, scripts. Identify patterns: a missing folder, a changed URL base, a removed prefix. Patterns are often fixed with a few redirect rules rather than hundreds of manual actions.
Set up a correction strategy: 301s, 410s, canonicals and fallback pages
A durable fix combines several levers:
1) 301 redirects : to send the user to the page closest to the original content. Essential when a URL has changed but the resource still exists.
2) 410 : if the page no longer exists and should not be replaced. It’s a clearer signal to search engines than a 404.
3) Canonical : useful if you have URL variations pointing to the same content (parameters, trailing slash, http\/https). The goal is to avoid duplication and consolidate signals.
4) Useful 404 page : even if you implement many redirects, there will always be erroneous URLs (typos, outdated external links). A well-designed 404 page offers an internal search, categories, and quick access to key pages, without automatically redirecting to the homepage (bad practice).
Do not confuse 404s with disguised security issues
After a migration, an increase in 404s can also come from hostile noise: automated scans looking for sensitive files, attempts to access known endpoints, or requests targeting vulnerable plugins. These 404s do not correspond to pages you actually lost, but to opportunistic attacks. They can inflate your reports and hide the real broken URLs.
To maintain a healthy posture, it is useful to know the common errors that expose your installation: The Most Common Security Errors.
Reduce noise: harden access to the administration area
Some 404 requests target the login page, xmlrpc.php, or extension paths. Reducing brute-force attempts improves stability, clarifies logs, and lowers the risk of incidents after migration (a time when some settings are sometimes forgotten). Here is a practical approach: How to Limit Login Attempts on.
What if the migration revealed (or caused) a compromise?
Less frequently, a poorly managed migration (outdated plugins, contaminated backup, reimporting dubious files) can leave unwanted elements behind. A compromised site may show strange behaviors: unknown redirects, pages disappearing, automatically generated URLs, or certain routes being blocked. If you suspect an incident, follow a remediation process: Hacked Cleanup and Hardening Steps.
Preserving SEO: avoiding rank loss due to 404s
404s aren't always catastrophic, but after a migration they quickly become a break signal: degraded user experience, reduced useful crawling, dilution of backlinks, and a gradual drop in visibility. The key is to restore continuity for strategic URLs. Sort them into:
– High-value URLs (traffic, conversions, backlinks): redirect as a priority.
– Secondary URLs: fix if simple (pattern), otherwise leave a clean 404.
– Noise URLs (scans, non-existent endpoints): don't overreact, but filter and secure.
Finally, monitor over time: some errors only appear after reindexing, or when a bot retries an old URL several weeks later.
Regular hygiene limits cascading effects and prevents small errors from becoming lasting SEO problems. On this topic, this resource is useful: Why a Non-Maintained Site Loses Search Rankings.
Discover our offers for WordPress website maintenance
10-step action plan to eliminate post-migration 404s
1) List real 404s via server logs + crawling tools.
2) Determine whether the 404 is from WordPress (theme) or the server (configuration).
3) Check permalink structure and re-save the rules.
4) Verify Apache/Nginx configuration (rewrite, root, index.php).
5) Compare content volumes (pages/posts/products/taxonomies) between the old and new site.
6) Inspect media: file presence, permissions, paths, external storage.
7) Re-import/re-deploy missing redirects (301), especially patterns.
8) Fix divergent slugs or redirect the variants.
9) Handle theme/plugin-dependent sections (CPTs, endpoints, accounts).
10) Set up continuous monitoring (new 404s, recurrence, bots).
When to delegate: save time and avoid recurrence
If your site is critical (e-commerce, lead generation, strong SEO), fixing 404s is not limited to patching URLs. It often requires coordinating the server, WordPress, redirects, performance, and security — then maintaining everything over time. Regular support helps anticipate regressions (updates, plugin changes, theme evolution) and keep a stable quality level.
For a guided solution, you can discover the services offered and choose a level of support suited to your site.
