When WordPress stops working after a hosting move, first confirm which server and database are serving the request. Then investigate the specific failure: application startup, missing content, URL handling, authentication, or a connected service. Changing several settings before identifying that boundary can hide the original problem and create a second one.
Common WordPress migration problems include database connection errors, blank pages, broken images, 404 responses, redirect loops, login failures, and missing email or checkout behavior. The same visible symptom can have different causes. A successful homepage visit also does not establish that forms, payments, current records, and scheduled work survived the move.
This guide provides a practical diagnostic sequence for authorized site owners and maintainers. Examples are illustrative, and the command shown is a qualified preview example, not something executed on your website. Multisite, custom deployment systems, and active stores may need a specialist plan beyond a standard single-site hosting transfer.
Match the symptom to the first useful check
Record the exact URL, time, browser, signed-in state, response, and recent action. Include whether the problem appears on the public domain, a private preview, or both. Those details help distinguish a broken destination from a request that never reached it.
| Symptom after moving hosts | First useful investigation | Avoid assuming |
|---|---|---|
| Old site, default page, or inconsistent content | Routing, hostname configuration, caches, and serving environment | Every mismatch is just DNS propagation |
| Database connection error | Active configuration, database endpoint, user access, and import | The database must be repaired or deleted |
| Blank page or critical error | Relevant server/application logs and runtime differences | Increasing every limit is the correct fix |
| Homepage works, inner pages fail | Request routing, existing content, and rewrite handling | Changing the site’s URL structure is necessary |
| Images or styling are missing | Failed resource URL, response, file presence, and generation | All failures are an incomplete uploads copy |
| Redirect loop or wrong destination | Each redirecting layer and intended hostname/scheme | More redirect rules will solve it |
| Login fails | Failure type, environment, URL/cookie state, and access controls | Repeated password resets address every case |
| Form or order looks successful but staff see nothing | Receiving and authoritative service records | A confirmation screen proves delivery or payment |
Use the table to choose an investigation, not a guaranteed diagnosis. Several faults can coexist after one move, but each still needs evidence and a controlled correction.
Protect current data before changing the destination
Preserve the source, destination, configuration, and available logs before substantial repairs. Label copies with environment and capture time. An archive containing the failed destination is useful evidence even when it is not a suitable recovery point.
Identify the current authoritative application. If customers can create orders, accounts, bookings, or inquiries, determine where those writes are landing. A fresh import from the old host can erase legitimate work already created on the new one.
Before restoration, reimporting, URL replacement, configuration edits, or component changes, have the authorized operator confirm backups, recovery access, the correct environment, and a current-data preservation plan. On a controlled copy, prevent unintended email, payments, subscription processing, fulfillment, or other external actions.
Keep a change record: hypothesis, evidence, proposed correction, affected scope, time, and result. Make one meaningful change at a time when practical. If an urgent incident requires several coordinated actions, record them explicitly rather than pretending the eventual result identifies one cause.
The WordPress migration checklist covers preparation and cutover planning. This article starts when something is already wrong and concentrates on finding the failing boundary without casually undoing current business activity.
- Confirm that you are testing the intended server
Compare the public route with the destination host’s supported preview method. Ask the host to confirm the assigned origin, hostname configuration, document root, and relevant request logs. Seeing the expected files in a control panel does not establish that public requests use that directory.
Inspect the relevant apex and subdomain records, including the address families and aliases actually used. A stale route for one hostname or address family can produce inconsistent results. Record authoritative answers separately from results observed through a local resolver or browser.
Where a proxy or CDN is involved, do not expect the public DNS answer to expose the origin. Cloudflare’s proxy-status documentation explains this distinction. Verify the configured origin through the provider’s controls and host evidence instead of comparing a proxied public address with the hosting account’s IP and declaring a mismatch.
Check browser, page, server, and edge caches according to the symptom. A stored response can make corrected source files look unchanged. Conversely, changing cache settings will not fix a domain attached to the wrong application. Inspect the actual receiving environment before repeating a transfer.
Use supported private preview methods that preserve the intended hostname and certificate context where needed. Do not disable certificate checks or globally change public routing simply to make a preview load. Remove any temporary local overrides once their diagnostic purpose is complete.
- Diagnose a database connection error precisely
Compare the database settings in the active installation with the destination provider’s actual values. Check the database name, user, password, host or endpoint, and required connection method. The database host is not universally the same value on every hosting platform.
The official wp-config.php reference explains the configuration and related overrides. Inspect the configuration actually used by the running site; a deployment may supply values through its own supported mechanism. Keep passwords and connection details out of public screenshots and ordinary support messages.
Have the host or authorized operator distinguish connection failure from insufficient privileges, an unavailable database service, or an import problem. Confirm that the intended tables and current records are present. An import tool reporting completion is evidence to review, not proof that every required table and row arrived correctly.
If WordPress offers a fresh-installation screen unexpectedly, stop before running setup. Verify the selected database, table prefix, imported content, and correct installation path. An empty-looking application may be connected to the wrong data rather than need a new installation.
Correct the verified mismatch through the provider’s supported process, then test again. Before reimporting or replacing data, preserve both environments and legitimate changes since the earlier export. Do not delete databases, grant broad access, or run repair operations merely because the error contains the word database.
Verify the copied state before repeating an import
A transfer can finish without representing the intended recovery point. Compare the source capture time, destination import time, and legitimate activity between them. Confirm that the files and database belong to a compatible state rather than assuming the newest archive contains everything needed.
WordPress documents file backups separately from the database. Review the selected tool’s actual coverage: uploads, custom directories, relevant hidden files, required configuration, and external storage may need different handling. An application archive does not automatically recreate the old host’s infrastructure.
Use identity as well as counts. The same number of products, posts, or orders can conceal different records or duplicates. Compare a relevant sample by stable source identifiers and business meaning, including the recent activity most likely to be missing from an earlier export.
If a transfer report contains warnings, retain them and investigate their scope. A large archive can encounter extraction, storage, access, or import limits. Identify the failed portion before rerunning the entire process or deleting the destination to create space.
Before corrective copying or reimport, preserve both environments and the current-data boundary. Use a supported scoped method and validate what changed. A broader repeat import can overwrite a successful earlier correction or erase new records while leaving the original host-level problem untouched.
- Investigate blank pages and critical errors using logs
Capture the failure time and inspect the relevant PHP, web-server, and application logs with the host or developer. Determine whether the request reached WordPress and which operation failed. A server error page can originate outside the normal application response.
Compare the source and destination web runtime: supported PHP environment, required extensions, file locations, ownership, and provider restrictions. A command-line PHP version can differ from the web process that serves visitors. Check the actual environment used by the failing request.
WordPress provides debugging guidance, including separate logging and display controls. Use an appropriate controlled environment or scoped authorized setup. Keep errors and logs private, avoid exposing sensitive paths or request data publicly, and restore the intended diagnostic settings afterward.
If a component is implicated, test a supported correction or isolate it on a protected copy. Preserve its current settings and understand dependencies before changing it. Disabling a payment, membership, or language component on production can interrupt legitimate work even if the homepage begins loading.
A memory-related message, missing function, permission error, and syntax failure need different corrections. Ask the operator to explain the finding rather than raising every limit or switching to an unsupported runtime. The WordPress critical-error guide provides a deeper investigation when application startup is the failing boundary.
- Fix post-migration 404s without redesigning the URLs
Check a known existing page and determine which layer returns the 404. A web-server default page, a WordPress not-found template, and a CDN-generated response can point to different investigations. Compare the requested address with the content and URL inventory from before the move.
If the content exists but its readable address does not resolve, inspect how the destination routes requests to WordPress. The server’s rewrite configuration must support the actual installation. Apache-style configuration is not a universal solution for Nginx or every managed platform.
The WordPress permalink documentation explains URL structures. If the authorized operator determines that WordPress rewrite rules need refreshing, preserve current settings and recovery material before saving the existing permalink configuration. That operation does not automatically repair unrelated server rules or missing content.
Do not select a new permalink structure as an experiment on a live established site. Changing addresses can create a second migration problem and additional redirect work. First try to restore the intended behavior for the original valid addresses.
If paths deliberately changed, use a reviewed source-to-destination map and appropriate redirects. Do not redirect every missing resource or page to the homepage. Verify relevant destinations, downloads, product links, and campaign URLs so the correction preserves the task visitors came to complete.
- Trace broken images and missing styles to the failed request
Use the browser’s developer tools or an authorized diagnostic process to identify a representative failed image, stylesheet, script, or font. Record the requested URL, status, and relevant error. Inspect the result directly without assuming every missing visual asset has the same cause.
A 404 can mean the file was not transferred, the generated variant does not exist, the path differs, or the request reaches the wrong location. A 403 suggests an access-control investigation rather than automatic proof that the file is absent. A browser security block may concern the request’s scheme or policy.
Compare the original media with the destination files and any external storage integration. Some installations offload media rather than keep every asset in a standard uploads directory. Include case-sensitive filenames, custom content locations, generated CSS, and host-specific optimization output where relevant.
Repair the confirmed source through the appropriate tool or provider workflow. If generated assets need rebuilding, identify which component generates them and test representative layouts afterward. Do not broaden permissions across the whole installation or regenerate every possible file without an understood need and recovery route.
When an HTTPS page requests insecure assets, use the WordPress mixed-content guide to locate the actual source. A rewrite or browser workaround can hide one symptom while leaving incorrect stored references or application settings unresolved.
- Separate redirect loops from incorrect destinations
Record the redirect sequence for the failing hostname and path. Identify whether each response comes from the edge, host configuration, WordPress, or another component. Include the scheme and hostname at every step rather than treating all redirects as one setting.
For Cloudflare users, its redirect-loop documentation explains how encryption mode and origin behavior can conflict. The destination needs an appropriate certificate and supported end-to-end configuration. Adding another HTTPS plugin or weakening transport settings without identifying the conflict can make diagnosis harder.
Check competing rules for HTTP and HTTPS, www and non-www, old and new domains, and temporary preview addresses. A hosting move that preserves public URLs does not inherently need a new set of domain-change redirects. Old server rules and new defaults should have clearly assigned responsibilities.
Before editing redirects or transport configuration, preserve the current rules and access needed to recover. Make a scoped correction through the responsible provider. Do not globally disable security controls or copy an unrelated installation’s proxy-handling snippet into production.
Use the Cloudflare and WordPress redirect guide for a deeper layer-by-layer review. After correction, test an ordinary content page, login, and the relevant business path rather than only the root address.
- Investigate login failures by their actual behavior
Distinguish a rejected password from a login page that loops, a blocked request, a blank administration screen, or a security challenge. These cases need different evidence. Repeatedly resetting a password will not fix a request that never reaches the intended installation.
Confirm that you are using the correct destination and canonical URL. A domain or scheme mismatch can affect cookies, redirects, and session behavior. A temporary preview URL may not behave like the final hostname and should not automatically be written into production settings.
WordPress’s logging-in handbook covers authentication and common cookie/session issues. Where appropriate, test a fresh browser context or clear only the relevant site’s stored state, recognizing that this signs you out. If the problem persists, inspect the server and application path rather than repeating the browser test indefinitely.
Have the responsible operator check session-sensitive cache behavior, relevant firewall findings, authentication integrations, and any migrated URL or cookie overrides. Use narrow authorized corrections. Do not disable every protection layer globally or create an unrestricted administrator account as a routine diagnostic shortcut.
If password recovery is needed, use the supported account-recovery route and verify its receiving email path. Preserve legitimate users and permissions; do not restore an older user database over current account changes simply to recover one login.
- Check URL changes only when they actually occurred
First decide whether the move changed the public domain, scheme, path, or installation location. A host-only transfer retaining the same public URLs is different from moving to another domain. Unnecessary replacements can damage valid content and configuration.
The WordPress migration handbook explains the different cases and the risk of mishandling serialized data. Confirm the intended site and WordPress addresses and any configuration overrides. They are not necessarily identical when WordPress files live in a different directory from the public site.
If stored references genuinely need correction, use a supported serialization-aware method with a reviewed scope. Preserve backups, current legitimate records, and a recovery route first. Do not run a blanket text replacement across an exported SQL file and assume all structured values remain valid.
The following is an illustrative WP-CLI preview for an authorized operator on an identified controlled copy. Replace the reserved example addresses with the actual reviewed pair only when a URL change is intended:
wp search-replace 'https://old.example' 'https://new.example' --skip-columns=guid --dry-runThe documented search-replace command reports proposed database replacements without saving them when --dry-run is used. Review the installed tool, execution context, table coverage, and report. This is not a universal multisite command, and its report does not authorize removing the preview flag on production without a separate scoped change plan.
- Restore email as a separate service path
Separate staff mailboxes, website-generated messages, and form notifications. They may use different providers even when the old hosting account originally sold them together. Moving website files does not recreate a mailbox or preserve its stored history.
If nameservers changed, compare the required DNS and verification records with the approved zone inventory and actual provider instructions. If only website address records changed, determine whether a mail hostname depended on the edited destination. Avoid adding guessed records or replacing the entire zone to fix one symptom.
For application mail, inspect the actual sending route, credentials, allowed connections, sender identity, and receiving result. The wp_mail() reference notes that a successful return does not prove the recipient received the message. Likewise, a form success screen is not an inbox-delivery receipt.
Use approved test content and trace the message through the relevant provider or application logs. Confirm receipt at the intended mailbox or business system. Keep private message contents and credentials out of public reports.
The WordPress email troubleshooting guide helps distinguish application, sending, routing, and receiving failures. Do not install an SMTP component automatically when the missing item is actually a mailbox, a DNS dependency, or a form event that was never created.
- Treat checkout and order inconsistencies as data problems too
An active store can receive writes and external events during a migration. Identify the authoritative order records, payment state, stock, fulfillment activity, and customer communication before attempting to replay or recreate anything.
Compare a reported failed purchase with the payment provider and the store’s actual records. A customer-facing error may occur after an external payment action, while an attractive confirmation page may still leave a missing callback or incomplete order transition. Do not infer financial state solely from the browser view.
Check the relevant integration’s current destination, access, webhook or callback behavior, and supported configuration. Use approved test modes for new tests and reconcile real incidents through authorized business and provider records. A migrated credential may be present while an external allowlist or provider setting still needs attention.
Before a restore or reimport, preserve legitimate new orders and define a supported reconciliation method. Blindly copying an older database into the new store can discard valid obligations. Running two uncontrolled live writers can create a different problem while you investigate the first.
The WooCommerce checkout troubleshooting guide provides a focused workflow. Close a migration-related commerce issue only when the affected records and customer task are understood, not when a developer can merely load the checkout page again.
- Review scheduled jobs and background integrations
Some business work happens after the visible request. Backups, scheduled publications, subscription tasks, imports, notifications, and synchronization can rely on application events or host-managed scheduling that the migration archive did not recreate.
Inventory the relevant jobs and identify their owner, execution method, last observed activity, and expected result. Compare the source and destination setup. A copied application setting does not establish that an external scheduler now invokes the destination correctly.
If a job stopped, investigate its trigger, runtime errors, permissions, connectivity, and supported destination configuration. If it ran twice, determine whether the source and destination both remained active. Avoid assuming that rerunning every pending task is a harmless fix.
For consequential work such as payments, customer messages, or fulfillment, reconcile the authoritative result before any replay. Ask the integration owner how retries and duplicate detection operate. Use the provider’s supported recovery process rather than a generic bulk-action experiment.
Record paused legitimate work and its eventual owner. A temporary incident control can remain unnoticed after the public site recovers. The final review should include the operational tasks that visitors cannot see but the business still depends on.
- Investigate slowness after the move without guessing at capacity
Compare representative requests and the relevant source baseline, if one exists. Distinguish slow server responses from large assets, delayed external scripts, or browser-side work. A faster hosting plan cannot directly correct every kind of slow experience.
Check what infrastructure-dependent behavior changed: application cache, object storage, optimization output, database connectivity, and host-managed components. A copied host integration may no longer fit the destination, while a missing required component may remove an intended capability.
Ask the host and developer to examine the failing path and relevant resource evidence. Document the actual web runtime and configuration rather than assuming that a control-panel limit is the limit used by the request.
Restore a documented supported setup and test the relevant pages and business functions. Do not leave old and new caching systems active together without understanding their roles. Purging every layer can temporarily change observations without resolving the cause.
Keep the conclusion bounded. If one representative page improves after a specific correction, record that result and its conditions. Do not claim that every page, device, and external integration has been optimized or that search traffic will automatically increase.
- Check search-facing output after functional recovery
Inspect the intended public pages for accidental staging restrictions, authentication, incorrect canonicals, stale sitemaps, and unexpected redirects. A site can look normal in an administrator session while ordinary visitors or crawlers receive a different response.
Google’s hosting-change guidance addresses moves without user-visible URL changes. Keep that case separate from a domain or path migration. Use the appropriate search monitoring and do not invent URL changes or redirect work that the hosting move did not require.
Where addresses changed intentionally, review the approved mapping and the actual destination of important links. Fix the underlying response or content problem before repeatedly submitting affected pages for indexing.
A performance-report query about an indexing problem is not proof that your own site has that problem. Use the actual page status and inspection evidence for the relevant URL. Search reporting can also lag behind a technical correction, so keep the performed fix separate from later external observations.
Record the public state checked, date, and remaining limits. Functional recovery, data reconciliation, and search recovery are related workstreams with different evidence. None should be declared complete solely because another one produced a positive signal.
Choose rollback according to the data boundary
A rollback can mean reverting application files, restoring data, changing traffic routing, or reversing a provider setting. Those are different operations. Decide which one addresses the verified fault before treating return to the old host as a single universal remedy.
Identify legitimate activity created since the relevant recovery point. Preserve it through an authorized supported method before replacing data or redirecting writes. A backup from before the move may be technically usable and still omit current orders, leads, or account changes.
DNS reversal does not undo transactions or instantly make every visitor reach the same environment. Coordinate the authoritative site, external event destinations, and staff instructions. Do not allow the old application to resume uncontrolled business processing while the new one still receives activity.
If the remaining problem can be corrected safely in place, compare that route with the consequences of rollback. If recovery access, data integrity, or an essential task cannot be established, involve the host and responsible developer before further consequential action.
Record the decision, preserved records, dependencies, and checks needed afterward. Recovery should leave another authorized maintainer able to understand what changed and why.
Send a handoff that helps the next operator act
A useful support request identifies the failing task and the evidence available. State the authorized environment, whether public URLs changed, when the move and symptom occurred, and which functions still work. Include the time zone so the host can correlate the request with its logs.
Provide a representative failing address and a concise expected-versus-observed description. For example, say that a known product page returns a particular response while the homepage loads, rather than saying only that the website is broken. Keep private query parameters, session material, and customer details out of an ordinary ticket.
Describe the changes already attempted and their results. An operator needs to know whether a configuration edit, restore, cache purge, or account change occurred after the first failure. Preserve the original finding even if later attempts altered the visible symptom.
Ask a scoped question appropriate to the recipient. The host can confirm request routing, relevant server errors, database access, and infrastructure visibility. The application maintainer can review component behavior and stored configuration. The business owner can identify the records and customer obligations that must survive recovery.
Name one coordinator for consequential actions. Several providers can investigate independently, but simultaneous undocumented changes make cause and effect difficult to assess. Use restricted evidence references and agreed access methods rather than forwarding raw credentials or a full customer export to every participant.
Work through two illustrative investigations
Imagine a fictional business whose public homepage looks outdated after migration. Staff see the expected destination through a private preview and assume public DNS merely needs more time. The host’s request evidence instead shows that one public hostname still uses a different configured destination. The team corrects that specific route and verifies fresh public pages before changing anything inside WordPress.
Now imagine a fictional store with a working homepage and complaints about checkout. The team first preserves the current records and checks the relevant payment and order evidence. It identifies an integration dependency that was not updated during the move and uses the provider’s supported correction and reconciliation process. It does not erase newer orders with an earlier export or retry payments based only on a browser error.
These are planning examples, not customer findings. Their useful similarity is the method: establish the serving environment, protect legitimate activity, identify the failing boundary, make a scoped correction, and verify the actual business outcome.
Use a recovery acceptance record
Keep a short register of findings, performed checks, owners, and open dependencies. Mark a task complete only when its actual evidence exists. “Should work now” is a prediction, not a result.
| Workstream | Completion evidence to record |
|---|---|
| Routing and installation | Intended environment receives the relevant public request |
| Files and database | Correct compatible state with required current records |
| URLs and presentation | Representative pages, resources, and redirects behave as intended |
| Access | Authorized login and recovery route work in the intended context |
| Customer tasks | Controlled inquiry, booking, or approved commerce path reaches its authoritative result |
| Background work | Required jobs and integrations have scoped verification |
| Release and support | Temporary measures reviewed, owners assigned, and unresolved limits visible |
Keep sensitive logs, exports, and credentials in approved restricted storage. A handoff can cite their location without attaching everything to every ticket. The objective is a reviewable recovery decision, not a publicly shared archive of the business’s infrastructure.
Retire temporary measures and the old environment deliberately
After the main fault is corrected, review what was changed for diagnosis. A private preview route, paused queue, temporary access rule, diagnostic logger, or test receiving address can remain after the homepage looks normal. Record whether each item should be removed, restored, or retained as an approved permanent change.
Confirm that ordinary maintenance now uses the intended destination. The next backup, deployment, or scheduled task should not pull stale state from the old host or recreate an earlier configuration. Test the relevant normal process through its supported controls rather than assuming the emergency correction changed every automation.
Keep the old environment available according to the agreed recovery and retention plan until its remaining dependencies are resolved. A site may still rely on an old mail service, downloadable file location, or external callback. Canceling the hosting package can affect more than the directory you moved.
Before cancellation or destructive cleanup, have the authorized owner confirm retained records, recovery coverage, and service acceptance. Separate required evidence retention from an operational site that should no longer process live work. Close temporary access and duplicate processing through the responsible provider’s supported method.
Frequently asked questions
Why is WordPress not working after migration?
The move may have changed routing, configuration, data completeness, runtime behavior, or a connected service. Start by establishing which environment serves the failing request, then use the exact error and relevant evidence. The timing of a move alone does not prove which setting caused the fault.
How long should I wait for DNS before troubleshooting?
Use the actual records, caching conditions, provider process, and observations rather than a universal waiting period. A domain attached to the wrong application or an outdated origin configuration will not necessarily correct itself with time. Separate authoritative configuration from cached results before deciding the next step.
Should I reinstall WordPress if the installation screen appears?
Stop and verify the active installation, selected database, imported tables, and table prefix first. The application may be looking at empty or unintended data. Preserve the current environments and recovery access before any setup, import, or replacement that could alter legitimate records.
Why do images fail when the pages load?
Inspect a representative failed resource URL and its response. Possible investigations include file coverage, paths, generated variants, external storage, access rules, and browser security blocks. The visible absence alone cannot distinguish them, and broad permission changes are not an appropriate first diagnosis.
Is search-and-replace required for every hosting move?
No. First determine whether the public URLs or relevant installation paths actually changed. Where stored references need correction, use a supported serialization-aware method with reviewed scope, backups, current-data protection, and a preview. Do not replace valid unchanged addresses merely because the server changed.
Why does login loop after moving hosts?
Confirm the destination and distinguish a redirect, cookie/session issue, blocked request, and rejected credential. Review the relevant URL, authentication, and caching context with an authorized operator. A fresh browser test can help isolate stored state but does not repair a persistent server-side mismatch.
Can I restore the old database to fix checkout?
Only through a justified recovery plan that preserves current legitimate activity and reconciles authoritative order and payment state. An older database can remove valid recent records. Investigate the failing integration first and avoid replaying payments or replacing data based solely on a browser symptom.
When should I ask the host or a developer for help?
Escalate when you lack the access or expertise needed to establish the serving environment, inspect relevant logs, preserve current data, or make a controlled correction. Provide the failing URL, timestamp, symptom, migration scope, and restricted evidence reference. Do not send raw passwords or customer exports in an ordinary ticket.
Recover the business task, not just the homepage
Effective migration troubleshooting connects the public request to the correct installation, preserves current records, and follows evidence through the failing layer. Verify the customer and staff tasks affected by the correction, keep remaining limits visible, and retire temporary measures deliberately.
Web Expert Solutions provides hosting migration and post-move support. If your moved site is failing, share the symptom, relevant URLs, move history, affected business functions, and available recovery points so the investigation can be scoped around the actual environment and data requirements.
