Moving a website to a new server often looks like a simple technical task: copy the files, move the database, update DNS records, and the website should work. But in real projects, this is exactly the moment when something can break.
The website may stop opening completely. Some pages may return 404 errors. The admin panel may not load. Forms may stop sending enquiries. Images may disappear. SSL may show a security warning. Or the website may look normal visually, but Google, analytics, CRM, or payment systems may already be receiving incorrect signals.
The main reason is simple: a website is not only a folder with files. It is a combination of domain settings, DNS records, server configuration, database, SSL certificate, redirects, CMS or framework logic, email settings, API integrations, caching, analytics, and SEO basics.
That is why, if a website is not working after moving to a new server, the worst thing you can do is start changing random settings. First, you need to understand where the problem is: domain, server, database, application, redirects, forms, or indexing.
Why a Website Can Break After Server Migration
After migration, the website starts working in a new technical environment. Even if the domain, design, content, and URL structure remain the same, the server itself may behave differently.
The old hosting could have one version of PHP, Node.js, MySQL, Apache, Nginx, or specific extensions. The new server may have different versions, different permissions, different rewrite rules, different memory limits, different email restrictions, or a different way of handling background processes.
The most common reasons why a website stops working after being moved to a new server include:
- the domain still points to the old server;
- DNS records have not fully updated yet;
- the SSL certificate is missing or installed incorrectly;
- the database was not imported correctly;
- the website still uses old database credentials;
- environment variables were not transferred;
- PHP, Node.js, or database versions are different;
- Apache or Nginx rules are not configured correctly;
- internal pages do not open because of routing issues;
- forms, email, CRM, or payment integrations stopped working;
- image, CSS, or JavaScript paths changed;
- cache still shows an old or broken version of the website.
The important thing is not to treat this as one general problem called “the website is down.” In most cases, the reason is specific and can be found through a clear technical check.
First, Understand How the Website Is Not Working
Before fixing anything, you need to identify the symptom. Different symptoms usually point to different technical layers.
What you seePossible reasonThe website does not open at allDNS, server, domain, firewallBrowser shows a security warningSSL certificate or HTTPS redirect issue500 Internal Server ErrorServer, code, database, permissions, versionsHomepage works, but inner pages do notRewrite rules, routes, permalink settingsWebsite loads without styles or imagesFile paths, permissions, mixed contentAdmin panel does not workSessions, cookies, permissions, database, configForms do not send enquiriesSMTP, email, API, CRM, reCAPTCHAGoogle sees 404 or 5xx errorsIncorrect server responses, redirects, robots.txt
This step saves time. If the issue is DNS, editing the code will not help. If the website cannot connect to the database, reinstalling SSL will not solve it. If inner pages return 404, the problem may be in server routing, not in the page content.
DNS: The Domain May Still Point to the Old Server
One of the most common migration problems is DNS. The website was moved, but the domain still points to the old server, or only part of the traffic reaches the new server.
After DNS changes, updates are not always visible immediately. Different providers, browsers, devices, and DNS servers may keep old records in cache. This is why one person can see the new website, another person can see the old version, and someone else may see an error.
What to Check in DNS Settings
The first things to check are:
- whether the A record points to the correct IP address;
- whether the www version is configured correctly;
- whether there is a conflict between A records and CNAME records;
- whether the correct nameservers are used;
- whether Cloudflare or another CDN is configured properly;
- whether subdomains still point to the old server;
- whether language or technical subdomains were also updated.
If the migration does not change the domain or URL structure, the SEO risk is usually lower than during a full URL migration. But the new server still needs to be accessible to users and search engines.
SSL Certificate: The Website Opens as “Not Secure”
Another common situation: the website opens, but the browser shows a warning that the connection is not secure. Or the website works on HTTP but fails on HTTPS.
This may happen because:
- the SSL certificate was not installed on the new server;
- the certificate was issued for the wrong domain;
- the www version or subdomain was not included;
- the certificate is installed but not served correctly;
- HTTP to HTTPS redirects are configured incorrectly;
- some page resources still load through HTTP.
For a business website, this is not just a technical detail. If users see a security warning, they may leave immediately. This is especially dangerous for contact forms, online stores, checkout pages, user accounts, and any page where personal data is entered.
What to Check After Installing SSL
After migration, open the website in all main versions:
- http://site.com
- https://site.com
- http://www.site.com
- https://www.site.com
All versions should lead to one main HTTPS version. If one version works, another shows an error, and another creates a redirect loop, SSL or redirect rules are not configured correctly.
500 Internal Server Error After Moving the Website
A 500 error means that the server received the request but could not process it correctly. For the user, it simply looks like the website is broken. For a developer, it means server logs need to be checked.
After migration, 500 errors often appear because the new environment does not match the website’s technical requirements.
Common Causes of 500 Errors
The most common reasons are:
- different PHP or Node.js version;
- missing PHP extensions or server modules;
- missing project dependencies;
- incorrect file and folder permissions;
- broken .htaccess file;
- wrong environment variables;
- failed database connection;
- insufficient memory or server limits;
- required application process is not running.
For example, a WordPress website may fail because a required PHP extension is missing. A Next.js or Node.js website may fail if dependencies are not installed, environment variables are missing, or the application process is not started through PM2 or another process manager.
In these cases, guessing rarely helps. Error logs usually show which file, module, connection, or configuration caused the failure.
Database Problems After Migration
Sometimes the website opens, but content is missing, pages look empty, products disappear, or the admin panel shows errors. In many cases, the reason is the database.
After moving the website, you need to make sure the database:
- was fully exported from the old server;
- was imported without errors;
- uses the correct encoding;
- contains all tables or collections;
- is accessible from the new server;
- is connected in the website configuration;
- has the correct user, password, host, and database name.
For CMS-based websites, the issue may be in wp-config.php, config.php, or another configuration file. For framework-based projects, the issue is often in .env files or environment variables.
Encoding is also important. If text becomes unreadable, strange symbols appear, or some content does not display correctly, the problem may be in database export, import, or character set settings.
Homepage Works, but Inner Pages Show 404
A very common case: the homepage opens correctly, but all inner pages return 404. This usually points to rewrite rules or routing.
For WordPress, it may be related to permalink settings or .htaccess. For Nginx, it may be an incorrect location configuration. For Laravel, Next.js, Nuxt, OpenCart, or custom systems, the reason may be in application routing, server proxy settings, or how requests are passed to the application.
If important URLs disappear after migration, this becomes both a user experience issue and an SEO risk. Pages that used to receive traffic from Google may suddenly become unavailable.
In this case, it is worth reviewing how a 404 error affects SEO, especially if the website had organic traffic before migration. A single broken URL may not be a disaster, but broken service pages, blog articles, product pages, or category pages can lead to lost traffic and fewer enquiries.
Images, Styles, or Scripts Do Not Load
Another migration issue is when the website technically opens, but looks broken. Styles are missing, images do not load, menus do not work, or blocks appear distorted.
This usually happens because of file paths, permissions, missing folders, or mixed content.
After migration, check:
- whether all media folders were transferred;
- whether file and folder permissions are correct;
- whether paths to uploads, storage, public, or static are correct;
- whether old domain or IP links remain in the code or database;
- whether CSS and JavaScript files are not blocked;
- whether HTTPS pages are not loading HTTP resources;
- whether CDN settings are correct.
For an online store, this can directly affect sales. If product images do not load, trust drops. If scripts are broken, the cart, filters, checkout, or product options may stop working.
Forms, Email, CRM, or Payments Stopped Working
After migration, many website owners only check whether the homepage opens. But a website can look normal and still stop generating leads.
The most common things that break after server migration are:
- contact forms;
- SMTP email sending;
- CRM integrations;
- Telegram or Viber notifications;
- payment systems;
- delivery API;
- reCAPTCHA;
- webhooks;
- analytics and conversion events.
These features often depend on server settings, tokens, IP addresses, environment variables, or third-party services. For example, the email provider may block sending from a new server IP. CRM may accept requests only from the old server. A payment system may have a callback URL that no longer works correctly.
That is why migration testing should include the full user path: opening the website, submitting a form, receiving an email, sending data to CRM, tracking analytics events, and completing a purchase or payment if the website has e-commerce functionality.
Cache: Why the Website Looks Different for Different Users
After migration, different people may see different versions of the website. One user sees the old website, another sees the new website, and another sees an error.
This is often caused by cache:
- DNS cache;
- browser cache;
- CMS cache;
- server cache;
- CDN cache;
- Cloudflare cache;
- page cache;
- static file cache.
Cache itself is not bad. It helps the website load faster. But during migration, it can make diagnostics harder because not everyone sees the same version of the website.
After moving the website, cache should be cleared carefully at all relevant levels: CMS, server, CDN, and browser. But this should be done thoughtfully, because cache clearing should not hide the real technical reason behind the issue.
How Server Migration Can Affect SEO
If the website is moved correctly, URLs remain the same, and downtime is minimal, SEO risks are usually manageable. Problems start when migration creates technical errors that search engines can see.
Google does not evaluate migration only as a “server change.” What matters is what search engines receive after the move: whether pages are accessible, what status codes they return, whether content is still available, whether redirects work, and whether technical SEO elements remain correct.
What Can Harm SEO After Migration
The biggest risks include:
- long website downtime;
- important pages returning 404;
- server errors returning 500;
- changed URL structure without redirects;
- missing meta title and description;
- canonical tags pointing to old URLs;
- robots.txt blocking important pages;
- sitemap containing broken URLs;
- slower page loading;
- broken language versions or hreflang tags.
After migration, it is important to check Google Search Console: indexing reports, page status, sitemap, crawl errors, mobile usability, and the most important URLs through the URL inspection tool.
What to Do If the Website Already Stopped Working
If the website has already been moved and is now broken, act step by step.
1. Do Not Delete the Old Server Immediately
The old server should remain available for at least a short transition period. It may be needed to compare files, database versions, configuration files, media folders, logs, or to roll back quickly.
The worst situation is when the old hosting has already been removed, backups are incomplete, and the new website does not work.
2. Check Domain and DNS
Make sure the domain points to the correct IP address, the www version works properly, nameservers are correct, and Cloudflare or another CDN does not create conflicts.
3. Check SSL and Redirects
The website should open through HTTPS without warnings, redirect loops, or conflicts between www and non-www versions.
4. Check Server Logs
Logs often show the real reason faster than manual testing. They can reveal database connection errors, missing files, permission problems, incompatible modules, or code errors.
5. Check the Database
Make sure all data was transferred, credentials are correct, the website connects to the new database, and no import errors occurred.
6. Test Key Website Scenarios
Do not stop after opening the homepage. Check:
- homepage;
- service pages or categories;
- product pages;
- blog articles;
- contact forms;
- cart;
- checkout;
- payment;
- admin panel;
- search;
- mobile version;
- analytics;
- sitemap and robots.txt.
For a commercial website, every untested function may mean lost enquiries.
How to Move a Website to a New Server Correctly
To avoid problems, website migration should be prepared before the final switch.
Before Migration
Before moving the website, create a full backup of files and database, document the current URL structure, check access to domain, hosting, CMS, database, email, CDN, analytics, and third-party integrations.
The new server should also be prepared in advance: correct software versions, database access, SSL, email settings, permissions, dependencies, environment variables, and test launch.
During Migration
During migration, avoid making too many changes at once. If you move the website, change the design, update the CMS, rewrite content, change URLs, and edit SEO settings at the same time, it becomes much harder to understand what caused a problem.
A safer approach is to migrate the website first, make sure it works correctly, and only then make further improvements.
After Migration
After launch, check technical responses, speed, forms, redirects, sitemap, robots.txt, indexing, analytics, and enquiries.
If the website is important for sales, one-time testing is not enough. During the first days after migration, monitor logs, leads, Google Search Console, and user behavior.
When You Need a Developer or Technical Website Support
If the issue is limited to DNS or SSL, it may be solved quickly. But if the website shows 500 errors, cannot connect to the database, has a broken admin panel, loses forms, or important pages disappear from Google, random experiments can make the situation worse.
In such cases, you need a developer who can check the server, code, database, logs, configuration files, redirects, integrations, and SEO-related technical risks.
And if the website regularly needs updates, backups, form checks, speed improvements, and stability monitoring, technical website support should be treated as an ongoing process, not only as an emergency fix after something breaks.
Conclusion
If a website is not working after moving to a new server, the reason is not always in the website itself. The problem may be in DNS, SSL, database connection, server configuration, software versions, file permissions, cache, redirects, or third-party integrations.
The most important thing is not to fix everything randomly. First, identify the symptom, check the technical layer, review logs, test key pages, and make sure the website works correctly for both users and search engines.
A proper server migration is not just copying files. It is a technical process that should protect website stability, leads, SEO visibility, speed, and user trust.
FAQ
Why is my website not opening after moving to a new server?
The most common reasons are DNS issues, incorrect server configuration, missing SSL certificate, database connection problems, wrong environment variables, or differences between the old and new hosting environment.
How long does DNS update take after moving a website?
DNS changes may not become visible immediately for everyone. Some users may see the new server, while others may still see the old version because of DNS cache at provider, browser, or device level.
Why does the homepage work but inner pages show 404?
This often happens because of routing or rewrite rules. The issue may be related to .htaccess, Nginx configuration, permalink settings, CMS routing, or how the server passes requests to the application.
Why do I see a 500 error after server migration?
A 500 error usually means a server-side problem. It may be caused by incompatible PHP or Node.js versions, missing extensions, wrong permissions, broken configuration files, database errors, or missing environment variables.
Why did forms stop working after migration?
Forms may depend on SMTP, email service settings, CRM integrations, API keys, reCAPTCHA, or webhooks. After moving to a new server, IP addresses, tokens, callback URLs, or environment variables may need to be updated.
Can moving a website to a new server hurt SEO?
Yes, if the migration causes downtime, 404 or 500 errors, broken redirects, missing meta tags, incorrect canonical tags, robots.txt issues, sitemap errors, slower loading, or problems with language versions.
Should I change URLs when moving a website to a new server?
If the goal is only to change hosting or server infrastructure, it is usually better to keep URLs unchanged. URL structure changes should be handled separately with a clear redirect plan.
What should I check first after moving a website?
Check DNS, SSL, homepage, inner pages, admin panel, database connection, forms, email, payment, mobile version, sitemap, robots.txt, redirects, speed, analytics, and Google Search Console.
