If your WordPress site looks broken after a migration, the problem is usually not the content itself, but one or more site dependencies that did not move cleanly: theme files, plugin assets, database values, PHP settings, or cached URLs that still point to the old environment. In most cases, the site can be restored quickly once you identify whether the issue is coming from missing files, mixed content, incorrect permissions, or a mismatch between the WordPress database and the new hosting configuration.
Why WordPress can look broken after a migration
WordPress stores structure, styling, and functionality in multiple places. After a move to a new hosting account or a new server, the site may load without its CSS, layout, images, menus, or interactive elements. This often happens because WordPress migrations involve more than copying the public HTML. A full migration must include:
- the WordPress core files
- the
wp-contentfolder with themes, plugins, and uploads - the database
- the correct domain mapping
- PHP version and extensions compatible with the site
- file permissions and ownership
- cache layers, such as page cache, browser cache, or a CDN
When one of these pieces is missing or incorrectly configured, the site may appear partially loaded, unstyled, or completely broken. On managed hosting platforms and in control panels such as Plesk, these issues are usually traceable with a few checks.
Most common signs of a broken WordPress migration
After migration, you may notice one or more of these symptoms:
- pages load as plain text or without design
- images are missing or show broken placeholders
- menus, sliders, forms, or widgets no longer work
- the homepage looks different from the old site
- CSS and JavaScript files return 404 errors
- the site redirects to the old domain or to a staging URL
- some pages show “critical error” or white screens
- admin pages load, but the front end does not
These signs point to specific types of issues. Styling problems usually mean missing asset URLs, cache issues, or file permission problems. Functional problems often mean plugin conflicts, outdated PHP, or database values that were not updated during the move.
Check the migration basics first
Before changing settings, confirm that the migration itself was complete. This avoids spending time on symptoms instead of the cause.
Verify that the full site was copied
Make sure the following were migrated:
wp-config.phpwp-contentincluding themes, plugins, uploads, and cache folders- the database export and import
- any custom files in the site root
If the theme is missing, WordPress may fall back to a default theme or display a broken layout. If uploads were not copied, images and media files will disappear. If the database import failed, settings and content may be incomplete.
Confirm the domain and document root
After a move, the domain must point to the correct document root in the hosting panel. In Plesk, for example, the domain should resolve to the folder containing the WordPress installation. If the document root points to the wrong directory, the site may load a placeholder page, an empty folder, or an old copy of the website.
Check that DNS has fully propagated
If the domain was moved to new hosting, DNS changes may still be in progress. During propagation, some visitors may see the old version of the site while others see the new one. This can make a successful migration look broken when it is simply inconsistent across networks.
Why the design disappears after migration
The most common reason a WordPress site looks unstyled is that CSS files are not loading. This can happen for several reasons.
Wrong URLs in the database
WordPress stores the site URL in the database. If the site was moved from a temporary domain, subdomain, or old host name, many internal links may still point to the previous address. That includes stylesheet URLs, image paths, and links inside page builder content.
Check these values in the database or WordPress settings:
siteurlhome
If these still reference the old environment, update them to the current domain. If the site uses hard-coded URLs in content, perform a safe search-and-replace across the database.
Mixed content on HTTPS sites
If the new hosting account uses SSL but some links still use http://, browsers may block stylesheets, scripts, and images. This often makes the site appear broken even though the files exist.
Use the browser developer tools or a site scanner to identify blocked mixed content. Then update the URLs to HTTPS and make sure the SSL certificate is active for the domain.
Missing or inaccessible CSS and JavaScript files
If asset files return 404 or 403 errors, the issue may be file path, permissions, or web server configuration. Check whether the theme and plugin directories were copied correctly and whether the files are readable by the web server.
On Apache-based hosting, incorrect rewrite rules or a missing .htaccess file can also stop stylesheets and scripts from loading properly.
How to diagnose broken images and media
Broken images after migration usually mean one of three things: the uploads folder was not copied, the database still references old image paths, or the server cannot serve the files because of permission or path issues.
Check the uploads folder
Open the migrated site files and confirm that the wp-content/uploads folder contains the expected media files and year/month structure. If this folder is incomplete or empty, images that were uploaded in the previous hosting environment will not be available.
Inspect the image URLs
If the media library shows images but the front end does not, the database may contain old URLs. This is common after moving between domains, subdomains, or HTTP to HTTPS.
Review the page source and image URLs in the browser. If the paths still include the previous domain, update them with a controlled search-and-replace tool.
Check file permissions
Inconsistent permissions may prevent the web server from reading uploaded files. As a general guideline, directories should be readable by the server and files should not be overly restricted. If the hosting panel allows you to inspect ownership and permissions, confirm that they match the account setup used by the new environment.
When menus, forms, and sliders stop working
If the layout loads but interactive parts fail, the problem is often JavaScript-related. This can be caused by one or more of the following:
- plugin files were not migrated correctly
- a caching plugin is serving old assets
- the current PHP version is not compatible
- the site is blocking script execution because of a security rule
- the theme depends on files that were not copied
Disable caching temporarily
After migration, clear all layers of cache:
- WordPress cache plugin cache
- server-side cache in the control panel
- browser cache
- CDN cache, if used
Sometimes the old layout is simply being served from cache. If clearing cache fixes the issue, configure the cache again after confirming the site is stable.
Check plugin compatibility
A plugin that worked on the old host may fail on the new one if the PHP version, memory limit, or installed extensions differ. If the site breaks after a specific plugin is activated, disable that plugin and test again. Focus especially on page builders, security plugins, optimization plugins, and sliders, since they often rely on JavaScript and server-side resources.
Review PHP settings and server requirements
Migration problems are sometimes caused by the hosting environment itself. A site that was working on one server may break on another if the PHP version or configuration changed.
Match the PHP version to the site
Some older themes and plugins are not compatible with the latest PHP versions, while some newer WordPress installs require a recent version for security and performance. In the hosting control panel, check the selected PHP version for the domain and compare it with the site’s requirements.
Confirm required extensions
WordPress and many plugins rely on common PHP extensions such as:
- curl
- mbstring
- openssl
- xml
- zip
- gd or imagick for image processing
If an extension is missing, certain parts of the site may fail silently or produce errors only in specific areas like forms, backups, or image resizing.
Review memory limits and execution time
Large themes and page builders may require more memory than a basic default configuration provides. If a page loads partially or triggers a fatal error after migration, increase the PHP memory limit where appropriate and test whether the issue disappears. Managed hosting platforms often provide these settings in the control panel or allow them through PHP handlers.
Use the browser to identify the exact error
The browser developer tools can quickly reveal why WordPress looks broken after migration. Open the console and network tabs, then reload the page. Look for:
- 404 errors for CSS, JS, fonts, or images
- 403 errors caused by permissions or security rules
- mixed content warnings
- JavaScript errors that stop scripts from running
- redirect loops or unexpected redirects
These clues help separate file-level issues from database or server-level problems. For example, a 404 on the main stylesheet usually means the path is wrong, while a JavaScript error from a plugin may indicate incompatibility or incomplete migration.
Practical step-by-step fix after migration
Use this order to troubleshoot without making unnecessary changes:
- Back up the migrated site and database.
- Confirm that
wp-content, the database, and the theme files are present. - Check that the domain points to the correct document root.
- Verify
siteurlandhomein WordPress. - Clear all caches, including any server cache or CDN cache.
- Scan for mixed content and update old HTTP links to HTTPS.
- Inspect file permissions and ownership.
- Temporarily disable plugins to isolate conflicts.
- Confirm that the PHP version and extensions match the site’s needs.
- Review browser console and server error logs for exact errors.
This sequence usually resolves the most common layout and functionality issues without affecting content.
Special considerations when using Plesk or a similar control panel
In a hosting control panel, several settings can affect how a migrated WordPress site behaves. If your platform uses Plesk or a similar interface, check the following areas:
- domain hosting settings and document root
- PHP version and handler for the domain
- SSL/TLS certificate status
- server-side caching options
- error logs for the domain
- file manager permissions
- WordPress Toolkit or automated repair tools, if available
Some hosting platforms also provide WordPress migration assistants. These can reduce errors, but they still depend on valid source data and compatible server settings. If a migration tool completed successfully but the site still looks broken, the issue is usually in the site data rather than the copy process itself.
How to avoid a broken look in future migrations
The best way to avoid post-migration issues is to prepare the site before moving it.
- update WordPress, themes, and plugins before migration
- remove unused plugins and themes
- confirm the site works without warnings on the old host
- create a full backup, including database and files
- note custom settings, cache rules, and redirects
- use a staging copy when possible
- test the site on a temporary URL or hosts file entry before switching DNS
Testing in advance helps catch hard-coded URLs, PHP incompatibilities, and missing assets before visitors see them.
FAQ
Why does WordPress load without CSS after migration?
This usually means stylesheet URLs are wrong, HTTPS is mixed with HTTP, the cache is serving stale files, or the web server cannot access the CSS files. Check the browser console and confirm that the theme assets are present in the migrated files.
Why are images missing after moving a WordPress site?
The uploads folder may not have been copied completely, or the database may still reference the old domain. Also check file permissions and whether the site is forcing HTTPS while the image URLs still use HTTP.
Why do some plugins stop working after migration?
Plugin failure is often related to PHP version differences, missing extensions, incomplete files, or cached JavaScript errors. Disable plugins one by one to identify the one causing the problem.
Can a DNS change make the site look broken?
Yes. During DNS propagation, different visitors may reach different servers and see different versions of the site. This can temporarily create the impression that the migration is broken.
Should I replace URLs in the database after migration?
If the domain changed, or if the site moved from HTTP to HTTPS, then yes. A safe search-and-replace is often necessary to update internal links, asset paths, and embedded content.
What should I check first in the hosting panel?
Start with the domain document root, PHP version, SSL status, and error logs. These settings often reveal whether the problem is caused by the new hosting environment or by the site files and database.
Conclusion
When WordPress looks broken after a migration, the issue is usually traceable to a small number of causes: missing files, outdated URLs, cache, permissions, incompatible PHP settings, or incomplete database replacement. By checking the domain setup, media paths, SSL, browser errors, and server configuration in a structured order, you can restore the site without guessing.
If you manage WordPress in a hosting control panel, focus first on the document root, PHP version, and logs. In most cases, a broken-looking site is not a failed migration, but a configuration mismatch that can be corrected quickly once the underlying error is identified.