When WordPress looks broken after a migration, the cause is usually not a damaged site. In most cases, the files, database, or server settings have moved correctly, but something in the new hosting environment is not matching what the site expects. This can affect layout, images, CSS, JavaScript, plugins, permalinks, or even the whole admin area.
If you have just moved a WordPress site to a new hosting account, VPS, or managed platform, it helps to treat the problem methodically. Visual issues after migration are often caused by missing media paths, incorrect site URLs, file permission problems, caching conflicts, PHP differences, or Apache and .htaccess rules that were not carried across properly. In a hosting control panel such as Plesk, these issues are usually easy to isolate once you know where to look.
Why WordPress can look broken after migration
WordPress depends on both the filesystem and the database. When a migration changes the server, the document root, the domain mapping, or the runtime configuration, the site may still load but without its styles or scripts. A page can therefore appear as plain text, stretched, misaligned, or missing key elements even though the content is still there.
Common reasons include:
- Wrong site URL values in the WordPress database
- CSS or JavaScript files not loading because of broken paths
- Mixed content after moving from HTTP to HTTPS
- File permissions or ownership issues
- Old cache files being served from the browser, plugin, or server
- .htaccess or Apache rewrite rules not being restored correctly
- Plugin or theme files missing after the transfer
- PHP version or module differences between environments
Before changing too many settings, it is best to confirm whether the problem is visible to everyone or only to you. Open the site in a private browser window and, if possible, test on another device or network. This quickly separates a local browser issue from a server-side migration issue.
First checks after a migration
Start with the simplest checks. They often reveal the issue in minutes.
1. Hard refresh the site
Your browser may still be using old cached CSS or JavaScript. Try a hard refresh:
- Windows: Ctrl + F5 or Ctrl + Shift + R
- Mac: Cmd + Shift + R
If the site looks correct after this, the migration was probably fine and the issue was only browser cache.
2. Clear all caches
If you use a caching plugin, server cache, CDN, or object cache, clear them all. Also clear any cache in your hosting control panel if it exists. In managed hosting environments, cache layers may sit in front of WordPress and can continue to serve old assets after the move.
Check:
- WordPress caching plugin cache
- Browser cache
- CDN cache
- Server-side cache
- Redis or Memcached cache, if enabled
3. Confirm the domain resolves to the new hosting account
If DNS has not fully propagated, some visitors may still reach the old server while others see the new one. This can make the site seem unstable or broken. Verify that the domain points to the correct hosting platform and that the domain is attached to the right subscription or site root in your control panel.
4. Check whether images and stylesheets are missing
If the page content is visible but the design is broken, open the browser developer tools and inspect the Network tab. Look for 404 or 403 errors on files such as:
- style.css
- theme JavaScript files
- logo images
- fonts
- builder assets
If these files are missing, the problem is usually path-related, permission-related, or caused by incomplete migration of the theme assets.
Check the WordPress URL settings
One of the most common causes of a broken-looking WordPress site after migration is a mismatch in the WordPress Address and Site Address values.
These are stored in the database under:
- siteurl
- home
If the old domain, temporary URL, or IP address is still stored there, WordPress may try to load resources from the wrong location. That can cause missing CSS, missing images, redirect loops, or admin pages that do not render properly.
You can check these values in:
- WordPress admin, if the dashboard still works
- phpMyAdmin in your hosting control panel
- wp-config.php, if values have been hard-coded
If you moved from a staging domain or temporary migration URL to the live domain, make sure both values are updated to the final domain.
Fix mixed content after moving to HTTPS
If the old site used HTTP and the new hosting setup uses HTTPS, WordPress may still load some resources over HTTP. Modern browsers often block these files or mark them as insecure, which can break the layout or make parts of the page disappear.
Typical symptoms include:
- Stylesheet not applied
- Images missing or broken
- Padlock warnings in the browser
- Sections loaded without scripts
To fix this, update all internal URLs from HTTP to HTTPS in the database. This should be done carefully, ideally using a proper search and replace tool that understands serialized data. Many managed hosting platforms and control panels provide safe database tools or staging workflows for this task.
Also check:
- WordPress General Settings
- Theme options that store absolute URLs
- Page builder settings
- Widget content and custom HTML blocks
Look for file permission and ownership problems
If the migration copied files but not the correct permissions, WordPress may not be able to read the theme assets or may be blocked from writing cache files. This can result in partial loading, broken uploads, or admin screens that behave incorrectly.
Typical permission values are:
- Directories: 755
- Files: 644
In some environments, ownership also matters. If the files belong to the wrong system user after migration, the web server may not serve them properly. In a hosting control panel such as Plesk, you can often repair ownership or re-sync permissions from the file manager or domain settings.
Be careful not to use overly permissive values such as 777, since this creates security risks and is not a proper fix.
Check .htaccess and Apache rewrite rules
Pretty permalinks, some plugin features, and certain redirect rules depend on Apache rewrite rules in the .htaccess file. If this file was not copied correctly, or if the new hosting environment uses a different document root, WordPress URLs may fail or pages may load without the expected styling.
Things to verify:
- .htaccess exists in the correct web root
- It contains the standard WordPress rewrite block
- No custom rules are conflicting with the site
- Apache is allowing overrides where needed
If you can access the dashboard, go to the permalink settings and save them again. This forces WordPress to regenerate rewrite rules. If you cannot access the admin area, review the .htaccess file directly through the hosting file manager or FTP.
Review the theme and plugin files
A migration can be technically complete but still miss parts of the wp-content directory. If the theme folder, child theme, custom fonts, builder templates, or plugin files are incomplete, the site may load but look wrong.
Pay attention to:
- wp-content/themes
- wp-content/plugins
- wp-content/uploads
- wp-content/mu-plugins
- custom asset folders used by the theme
If the site uses a premium theme or page builder, check that the full license-based package is present and that any required companion plugin is installed. Some visual issues happen because the theme is active, but its required CSS or builder plugin is not.
Common theme-related symptoms
- Layout falls back to a basic theme structure
- Menus display in the wrong place
- Widgets disappear from sidebars
- Homepage sections collapse
- Typography or spacing changes unexpectedly
Check PHP version and server configuration
WordPress and many themes or plugins rely on a specific PHP version and certain extensions. If the new hosting platform uses a different PHP version than the old one, the site may still load but with broken functionality, missing blocks, or admin errors.
For example, a theme that worked on an older environment may not behave the same way on a newer PHP release if it contains outdated code. The reverse can also happen: a modern plugin may require a newer PHP version than the new hosting account is configured to use.
In your hosting control panel, confirm:
- Active PHP version
- Required PHP extensions
- Memory limit
- Upload limit
- Execution time
If you are using managed hosting, the platform may already include safe defaults, but it is still worth checking whether the site was migrated with the same PHP version as the source environment.
Test for plugin conflicts
Some plugins store layout data, rewrite rules, or front-end scripts that can break after a migration. A conflict may not have been visible on the old server, but differences in caching, PHP, or file paths can expose it on the new one.
To test this safely:
- Disable all plugins temporarily.
- Check whether the site layout returns to normal.
- If it does, re-enable plugins one by one.
- Identify the plugin causing the issue.
If you cannot access the dashboard, rename the plugins folder via FTP or file manager. This is a standard troubleshooting step and can quickly show whether a plugin is interfering with the front end.
Inspect the browser console for missing assets
When WordPress looks broken but the page source is present, the browser console can show the exact cause. Open Developer Tools and check for errors such as:
- 404 Not Found on CSS or JS files
- 403 Forbidden on asset files
- Mixed content warnings
- JavaScript errors from a plugin or builder
If a CSS file is returning 404, the path is wrong or the file is missing. If the file returns 403, permissions or security rules are likely blocking it. If a JavaScript error appears early in the load process, it can prevent the rest of the page from rendering correctly.
Special case: WordPress migration to a different document root
In some hosting environments, especially when using a control panel like Plesk, the site’s document root may change during migration. For example, the site may now be served from a different directory than before, or the domain may point to a subfolder rather than the public HTML root.
If the document root is wrong, WordPress can appear partially broken because it is serving the wrong files or looking for assets in the wrong place. Make sure the domain points to the correct directory and that the WordPress installation files are in that location.
Check that the following are aligned:
- Domain assignment
- Document root
- WordPress installation path
- URLs stored in the database
Practical step-by-step recovery checklist
If you want a fast recovery process, follow this order:
- Open the site in a private window and hard refresh.
- Clear all caches, including plugin and server cache.
- Check DNS and confirm the domain points to the new hosting account.
- Verify WordPress Address and Site Address in the database.
- Check for mixed content if the site now uses HTTPS.
- Inspect file permissions and ownership.
- Review .htaccess and regenerate permalinks.
- Confirm theme and plugin files were migrated fully.
- Match the PHP version and required extensions.
- Temporarily disable plugins to rule out conflicts.
- Use browser developer tools to identify missing assets.
This process usually isolates the issue without guesswork. In many cases, the site is not broken at all; it is simply loading the wrong assets or using outdated URL references after the move.
How hosting support can help
If you use managed hosting, support can often confirm whether the issue is related to the migration or to the application itself. A good hosting team can help check domain mapping, DNS, PHP settings, file ownership, server cache, and Apache configuration. If the migration was performed by the hosting provider, support may also be able to compare the source and destination environments to identify what changed.
Useful details to provide when you open a support request:
- The site URL
- The date and time of the migration
- What looks broken, and where
- Whether the issue affects the front end, admin area, or both
- Screenshots of errors or missing styles
- Any recent changes to plugins, theme, or PHP version
The more specific the report, the faster the diagnosis.
FAQ
Why does my WordPress site show plain text after migration?
This usually means the CSS files are not loading. Check the site URL settings, file paths, permissions, cache, and whether the stylesheet is being blocked or returning 404 errors.
Why are images missing after moving WordPress?
The most common causes are broken media URLs, incomplete uploads folder migration, mixed content, or incorrect file permissions. Confirm that wp-content/uploads was copied fully and that the URLs still point to the correct domain.
Do I need to change anything in wp-config.php after migration?
Sometimes yes. If URL values were hard-coded, or if database credentials changed, wp-config.php may need updates. It can also contain custom paths or caching settings that need review.
Can a PHP version change break the look of WordPress?
Yes. A different PHP version can affect themes, builders, and plugins. Even if the site still loads, scripts or layout functions may behave differently.
Is this a WordPress problem or a hosting problem?
It can be either. WordPress stores the content and URLs, but hosting determines PHP, Apache behavior, caching, and file access. After migration, the issue is often a mismatch between WordPress settings and the new hosting environment.
Should I reinstall WordPress to fix a broken look?
Usually no. Reinstalling WordPress rarely fixes migration-related visual issues and may create new problems. It is better to check URLs, caches, permissions, and asset paths first.
Conclusion
If WordPress looks broken after migration, the site is usually telling you that one part of the stack does not match the old environment. Focus first on URLs, cache, mixed content, file permissions, theme assets, rewrite rules, and PHP settings. In a managed hosting or Plesk-based setup, these checks are usually straightforward and do not require rebuilding the site.
With a structured check of the database, file system, and server configuration, most post-migration layout problems can be fixed quickly and safely. In many cases, a full re-migration is not necessary at all.