WordPress 404 after migration Dubai? Check the rewrites
Your homepage loads. The WordPress admin may still be accessible. But every service page, case study and contact URL returns a 404.
That is a fairly common post-migration pattern for Dubai businesses moving to a new host. It feels like the pages have vanished, so somebody reaches for a backup or starts copying the site again. Hold fire. When the homepage works but ordinary page URLs do not, the more likely issue is how the new server is routing requests into WordPress.
The useful distinction: missing pages or broken routes?
A WordPress page can still be present in the database, visible in wp-admin and linked in the menu, yet return a 404 publicly. The friendly URL, such as /services/website-maintenance/, needs the server to pass the request through WordPress so WordPress can find the matching page. If that rewrite step is missing, blocked or overwritten, the server may look for a real folder called services and give up.
WordPress 404 errors after a migration are often caused by permalink settings, Apache .htaccess rules, nginx location rules, site URL mismatches, old redirects or cached responses. Restoring the database does not usually repair any of those things. It can, however, make the handover messier by putting files, plugins and content back to different points in time.
Read the pattern before changing the migration
The exact combination of working and failing URLs is useful evidence. A homepage is commonly served from the site root, so it may load even where the server has no working rule for internal WordPress routes.
| What works or fails | What it suggests | First check |
|---|---|---|
| Homepage works, all normal pages 404 | Pretty permalink routing or server rewrites are likely failing | Permalink structure and rewrite configuration |
| Direct files such as an image load, but pages 404 | The server can serve files but may not be passing virtual URLs to WordPress | Apache .htaccess or nginx location rules |
| URLs using ?p=123 work, friendly URLs fail | WordPress and its database are likely responding, while rewrites are not | Permalinks, web-server rules and cache |
| Only selected old URLs 404 | Content, redirects or changed slugs may be involved | Redirect map, page status and URL history |
| Pages work when logged in but not publicly | Cache, CDN behaviour or redirect rules may differ by visitor state | Cache headers, CDN rules and browser tests |
The ?p=123 test is particularly handy where you have access to an affected page ID. If that direct WordPress query loads the expected page but its normal URL does not, it is strong practical evidence that the page was not lost in transit. The routing layer needs attention.
Start with the least destructive checks
- Confirm the affected pages exist in WordPress. Open a few failing pages in wp-admin and check that they are published, not private, draft or sitting in trash.
- Check WordPress Address and Site Address. In Settings, General, both should reflect the intended live domain and HTTPS version. A migration to a temporary URL can leave awkward leftovers behind.
- Resave the permalink settings once. Go to Settings, Permalinks and save the current structure without changing it. This asks WordPress to refresh rewrite rules. It is a sensible early check, but it cannot write configuration files where the server does not allow it, and it does not create nginx rules.
- Identify the web-server setup. Apache commonly uses an .htaccess file in the WordPress root. nginx ignores .htaccess entirely and needs its routing handled in the server block. Some managed hosts add another layer with their own cache or proxy configuration.
- Inspect redirects and caching. An old domain redirect, a CDN page rule or a migration plugin redirect can send certain routes somewhere unexpected. Test in a private browser window and, where possible, check the response headers rather than trusting one cached browser result.
Why resaving permalinks is worth trying, but not enough
Yes, resaving permalinks is usually a reasonable first move when the homepage works and internal WordPress pages return 404 errors. It is quick and reversible. But it is not a universal repair button.
On Apache, WordPress may need permission to update .htaccess, and Apache must allow those rewrite directives to apply. On nginx, the host needs a correct rule that falls unmatched requests back to index.php. A site migrated from Apache hosting to nginx hosting can therefore carry perfectly good WordPress files and database content into an environment that handles URLs differently.
A Dubai migration example
Picture a Dubai consultancy moving an existing WordPress website to a new hosting account over a weekend. The homepage opens on Monday morning, which looks reassuring. Every service page then returns a 404, including the contact page, while the pages are still plainly visible in wp-admin.
Resaving permalinks changes nothing. A direct page request using its ID does load. That narrows the issue considerably: WordPress can retrieve the page, but the host is not rewriting friendly URLs correctly. Correcting the nginx route rule is a far cleaner route than restoring Friday’s backup, repeating the migration and leaving everyone unsure which copy is now live.
Things best left alone until the route is understood
- Do not delete and recreate pages merely because their URLs fail.
- Do not run a broad database search-and-replace without confirming the live site URLs and backup point.
- Do not stack migration plugins on top of each other to see if one gets lucky.
- Do not restore an old backup over a partly working new site unless there is a clear recovery reason and an agreed rollback plan.
There are cases where content genuinely did not move, particularly after an incomplete export, a failed database import or a domain replacement gone wrong. But the homepage-plus-404 pattern deserves routing checks first. Separate missing content from broken routing before touching the migration again.
If the route rules, cache layers and redirects need hands-on diagnosis, website repair support in Dubai can help establish whether the fault sits with WordPress, the host configuration or the migration setup.
FAQ
Why does the WordPress homepage work after migration while other pages show 404?
The homepage can load directly from the domain root, while internal pages rely on permalink rewrites. If the new server does not send friendly URLs through WordPress correctly, the homepage may work even though service pages and posts return 404 errors.
Should permalinks be resaved first?
Usually, yes. Resaving the existing permalink settings is a low-risk first check. If it does not solve the issue, inspect the server routing rules, site URLs, redirects and caches rather than repeating the whole migration.
Message Standish Services on WhatsApp to review the migration routing problem. Check the routing layer before repeating the migration or restoring a backup.