🔄 Move a Website to VPS Without Losing SEO or Traffic

Migrating a website from shared hosting to a VPS is best handled not as a single action, but as a sequence of checks. The main goal is to preserve site availability, URL structure, email, and search signals.

A safe migration process looks like this:

Take an inventory of the website: files, database, PHP and MySQL versions, cron jobs, SSL, email, and DNS records.
Create a fresh backup of the files and database.
Prepare the VPS and install a compatible environment.
Transfer the files and import the database.
Launch the site on a temporary domain or run checks using the hosts file.
Check pages, forms, authentication, uploads, cron jobs, and email sending.
Compare URLs, 301 redirects, canonical tags, robots.txt, and sitemap.xml.
Lower the TTL for DNS records in advance.
Point the domain to the new IP address.
Check HTTPS, email, logs, indexing, and Search Console.
Do not shut down the old hosting until DNS has fully propagated and the new server is running reliably.

The most common mistake is changing DNS before a test launch. In that case, any issues with PHP, the database, file permissions, SSL, and configuration become visible to real visitors and search engine crawlers.

For SEO, it is important to keep the domain, URLs, and internal linking unchanged whenever possible. If page addresses do change, each old URL must have a correct 301 redirect configured to the new one.

Domain email must not be overlooked either. Changes to the DNS zone can affect not only the website, but also MX, SPF, DKIM, and DMARC records. If you move only the A record and accidentally overwrite the other settings, emails may stop being received or sent correctly and may end up in spam.

After the switch, check robots.txt, sitemap.xml, canonical tags, redirects, response codes, and messages in Google Search Console. It is best to keep the old hosting active for a few more days so that some users with an outdated DNS cache continue to receive a working version of the site.

Please note in particularthat migrating a website affects not only the server, but also page availability, email operation, DNS, SSL, and search indexing. If the website generates leads, sales, or other critical traffic, it is better to entrust the migration to a specialist: they will check the environment in advance, prepare a rollback plan, and perform the switchover with minimal downtime. If that is not possible, this guide can be used as a basic checklist for a careful migration: it helps you go through the main steps, avoid forgetting anything, and reduce the risk of traffic loss.

Preparing for a Website Migration

Inventory of Files, Database, and Domain

Before migration, you need to document the components that make up the site and the services associated with the domain. Without an inventory, it is easy to migrate only the files and overlook the database, cron jobs, a separate subdomain, or a DNS record.

At a minimum, include:

The site directory and user uploads;
The database and its connection details;
Configuration files and environment variables;
Cron jobs;
Redirect rules;
The SSL certificate and HTTPS settings;
Domain DNS records;
Mailboxes and mail routing;
Subdomains, APIs, and external integrations.

It is useful to save a list of important URLs, current response codes, canonical tags, the contents of robots.txt, and the sitemap.xml URL in advance. After the migration, this data will help you quickly compare the old and new versions of the site.

Once the project’s components have been documented, you can determine which software environment will be required on the VPS.

Checking PHP, MySQL, and extension versions

A site may fail to run on a new server even if the files and database were migrated without errors. A common cause is an incompatible PHP, MySQL, or MariaDB version, or a missing extension.

On the old hosting environment, identify:

The PHP version;
The MySQL or MariaDB version;
The list of active PHP extensions;
The memory_limit, upload_max_filesize, and post_max_size settings;
The web server in use;
The versions of the CMS, framework, and core modules.

For PHP, you can check the version with the command: php -v

The list of extensions is displayed as follows: php -m

You can check the MySQL or MariaDB version with the command: mysql –version

On standard hosting, this information may also be available in the control panel or on the CMS diagnostics page.

You do not always need to install exactly the same software versions. However, before upgrading PHP or the database, it is important to verify compatibility with the CMS, theme, plugins, and custom code. Performing a migration and a major environment upgrade at the same time makes it harder to identify the cause of an error.

After verifying compatibility, you can proceed to back up the source site.

Fresh backup before starting the migration

The backup should be created immediately before the migration, especially if the site regularly receives new orders, comments, registrations, or uploads.

The minimum set should include:

A full archive of the files;
An up-to-date database dump;
Copies of the configuration files;
A DNS zone export or a list of records;
A separate copy of the redirect rules;
Details of cron jobs and background processes.

A week-old archive is not suitable for the final migration of a dynamic site: it may be missing new users, orders, and posts.

For projects with an active database, it is better to split the migration into two stages. First, copy the bulk of the data and test the site; then, before the DNS cutover, temporarily restrict changes on the old environment and create the final dump.

The backup should not be stored only on the old hosting account or only on the new VPS. At least one copy should be kept separately: on a local computer or in external object storage.

However, even a full site archive does not cover services that operate through the domain’s DNS.

Taking email and other domain services into account

The DNS zone does more than make the website accessible. It can also be used for corporate email, subdomains, third-party services, domain verification, and anti-spam settings.

Before migration, save the current records:

A and AAAA records for the website and subdomains;
CNAME records for aliases;
MX records for receiving email;
TXT records for SPF and service verification;
DKIM records;
DMARC policy;
records for APIs, CDNs, and other integrations.

If the website is being migrated to a VPS while email remains with the previous provider or a separate provider, there is no need to change the MX records. In most cases, it is enough to update only the website’s A records and, if necessary, its AAAA records.

It is especially risky to replace the entire DNS zone with the new provider’s template instead of changing a single record. In this case, email, domain verifications, and active subdomains may disappear.

After completing the inventory, checking the environment, creating a fresh backup, and saving the DNS zone, you can prepare the VPS for installing the website.

Preparing a VPS to Launch a Website

Installing a web server, PHP, and a database

Set up an environment on the VPS in advance that is compatible with the previous hosting platform. For a PHP-based website, this typically includes a web server, the PHP interpreter, the required extensions, and MySQL or MariaDB.

Nginx or Apache is most commonly used as the web server. The choice depends on the website’s current configuration, the CMS in use, and the rules already configured on the old hosting platform.

Before installation, check the following:

PHP version;
Required PHP extensions;
Database type and version;
.htaccess support, if the site uses Apache;
File upload and memory limits;
Rules for handling SEO-friendly URLs and redirects.

If the existing site runs on Apache with many rules in .htaccess, migrating to Nginx will require rewriting those rules manually. For this reason, during migration it is safer to first reproduce the familiar environment and leave optimization for a separate stage.

After installation, the services must be started and enabled to run at boot. It is also worth verifying that the web server, PHP, and the database are working before copying the site.

Once the environment is ready, you can create a separate database and application user account.

Creating the Database and User

The site should not connect to the database using the administrative root account. Create a separate database and user for it, with permissions limited to that database only.

Define the following in advance:

Database name;
Username;
Strong password;
Character set and collation;
Database connection address.

In most cases, the database runs on the same VPS, so the site configuration uses localhost or 127.0.0.1. A typical website does not need to expose the MySQL or MariaDB port to the internet.

After creating the database, test logging in as the new user and make sure the user can create, read, and modify tables only in their own database.

The connection details are then specified in the CMS or application configuration. It is better to store them in environment variables or in a private configuration file that is not accessible over the web.

After preparing the database, you can configure the site directory and virtual host.

Configuring the Virtual Host and Directories

A virtual host maps a domain to the site directory and defines how the web server handles requests.

For each project, you need to specify:

The domain and, if necessary, www;
The site root directory;
The index file;
PHP handling;
Redirect rules;
Access and error logs;
Restrictions on service files and directories.

For example, the website files may be located in the directory: /var/www/example.com/public

Configuration and secrets should be stored outside the public directory so the web server cannot accidentally serve them to a visitor.

File permissions must allow the web server to read the site, while allowing the application to write only to the directories where it is actually needed: uploads, cache, temporary files, and logs.

After configuring the virtual host, check the web server configuration for syntax errors, and only then reload the service.

At this stage, the site can still be run without changing DNS, using the hosts file or a temporary domain. However, HTTPS should be prepared before testing.

Preparing the SSL Certificate

An SSL certificate is required so the site loads over HTTPS without browser warnings. However, issuing a new certificate usually requires the domain to already point to the VPS or to pass DNS validation.

Therefore, before switching over, you can use one of the following options:

A temporary certificate for a test domain;
DNS validation for the domain;
Transferring the existing certificate, if its terms allow it;
Issuing a new certificate immediately after the DNS change.

If Let’s Encrypt is used with HTTP validation, port 80 must be open and the domain must point to the new server. Until then, the site can be tested over HTTP using the hosts file, and HTTPS can be checked immediately after the DNS switch.

Prepare the following in advance:

A redirect from HTTP to HTTPS;
Support for both the primary domain and www;
Automatic certificate renewal or a clear renewal procedure;
A correct certificate chain;
Availability of ports 80 and 443.

Do not enable forced HTTPS until the certificate has been successfully installed and verified. Otherwise, the test site may enter a redirect loop or become unavailable.

Once the environment, database, virtual host, and SSL configuration are ready, you can migrate the files and data from the old hosting provider.

Migrating Files and the Database

Copying Website Files

Website files can be migrated using rsync, scp, SFTP, or an archive from the hosting control panel. For a large project, rsync is more convenient: it preserves the directory structure, can transfer only changed data again, and is suitable for the final synchronization before the DNS switchover.

Example of copying a directory to a VPS: rsync -avz /path/to/site/ user@SERVER_IP:/var/www/example.com/public/

If the source hosting provider does not provide SSH access, you can download the files as an archive, upload it to the VPS, and extract it to the required directory.

Before migrating, it is important to check that the archive includes:

Hidden files;
.htaccess, if Apache is used;
User uploads;
Application configuration;
Service directories that the project actually needs.

Cache, temporary files, and old logs usually do not need to be migrated if the application recreates them.

After migrating the files, you need to migrate the current database.

Exporting and Importing the Database

For MySQL or MariaDB, the database is usually exported using mysqldump, phpMyAdmin, or the hosting control panel.

Export example: mysqldump -u old_user -p old_database > site.sql

The resulting file is transferred to the VPS and then imported into the previously created database: mysql -u new_user -p new_database < site.sql

For PostgreSQL, pg_dump and pg_restore are used, or the data is imported with psql.

Before importing, check the character encoding, dump size, and version compatibility. For a large database, you should also make sure the server does not limit the packet size or the operation execution time.

If the site continues to receive new data, the first dump is used for a test run. Before the final cutover, a fresh copy is created and imported again to avoid losing orders, registrations, or publications.

After the import, the next step is to verify the connections between the files, the database, and the new environment.

Checking Configuration and Paths

After the migration, the site configuration must point to the new database, the correct directories, and the current domain.

Check the following first:

Database name;
Username and password;
Database server address;
Absolute file paths;
Site URL;
Upload, cache, and log directories;
SMTP and external APIs;
Environment variables;
cron jobs and background processes.

On the old hosting environment, the path might have looked like /home/account/public_html, while on the VPS it might be /var/www/example.com/public. If the application stores absolute paths in its configuration or database, they need to be updated.

Do not blindly perform a bulk domain replacement in the SQL file. Some CMSs store serialized data where the string length matters. For such systems, it is better to use the built-in migration tools or dedicated commands.

After checking the configuration, you still need to make sure that the web server and the application have the correct access to the files.

File and Directory Permissions

Permissions that are too restrictive can prevent the site from writing uploads and cache data, while overly permissive settings increase the risk of files being modified by an unauthorized process.

Typically, the web server needs read access to the entire site and write access only to specific directories:

User uploads;
Cache;
Temporary files;
Application logs;
CMS update directories, if used.

Regular files often use permissions of 644, while directories use 755. However, the exact values depend on the user account under which the web server and PHP run.

It is also important to check file ownership. For example, the project may belong to a dedicated system user, while the web server is granted access through a group.

Do not use 777 as a universal fix. This approach hides the real issue with the owner or group and creates unnecessary risk.

After configuring permissions, open the site through a temporary domain or hosts file and verify that pages load, images are displayed, forms work, and the application can read and write data where required.

Test Run Before DNS Cutover

Testing using the hosts file

The hosts file lets you point a domain to the new VPS on a specific computer only. For all other users and search engines, the site will continue to open from the old hosting environment.

The following line is added to the file: SERVER_IP example.com www.example.com

After you save the changes, the browser will start accessing the new server through the regular domain name. This is useful for testing the virtual host, absolute links, cookies, authentication, and rules that depend on the domain name.

In Windows, the file is located at: C:\Windows\System32\drivers\etc\hosts

On macOS and Linux: /etc/hosts

It must be edited with administrator privileges. After making changes, you may sometimes need to clear the DNS cache or restart the browser.

During testing, it is important to make sure that you are reaching the new VPS. To do this, you can temporarily add a visible comment to the page, check the response header, or review the new web server’s access log.

After testing is complete, remove the entry from the hosts file; otherwise, that specific computer will continue to bypass public DNS.

If editing the local file is inconvenient, or if several people need access to the test environment, it is better to use a separate technical address.

Temporary domain or technical subdomain

A temporary domain or subdomain allows you to open the site on the new VPS without changing the primary DNS. For example, you can use the address: stage.example.com

A separate DNS record is created for it, pointing to the new server, and the corresponding virtual host is added to the web server configuration.

This option is convenient for collaborative testing, but it carries an SEO risk: the test copy may be indexed and start competing with the main site.

To prevent this, the test site must be locked down:

HTTP Basic Auth;
IP-based access restrictions;
VPN-based authentication;
noindex as an additional measure.

robots.txt alone is not enough: it restricts crawling but does not guarantee that the URL will not appear in search results via external links.

You should also keep in mind that some CMS platforms and applications hard-code URLs to the primary domain. Therefore, it is better to perform the final check of redirects, cookies, and canonical tags via the hosts file, using the site’s actual address.

Once the test version is available, you can proceed to testing user scenarios.

Checking Pages, Forms, and the User Account Area

The homepage alone does not confirm a successful migration. You need to check different types of URLs and the actions real visitors perform.

The minimum test scenario includes:

The homepage;
Categories and product or service detail pages;
Articles and archives;
Site search;
Contact forms;
Registration and login;
Password recovery;
The user account area;
The shopping cart and checkout;
File uploads and downloads;
The mobile version.

Pay particular attention to pages with parameters, filters, pagination, and SEO-friendly URLs. This is where issues with web server rules and URL rewriting are most likely to appear.

After submitting a form, check not only the success message but also whether the data was actually saved, whether the submission appears in the admin panel, and whether a notification was received.

For an online store or paid service, it is better to test external payments in test mode. Payment system webhooks may be tied to an IP address, URL, or SSL and may stop being delivered after the migration.

If the main user scenarios work, the remaining step is to check the application’s internal components.

Testing PHP, MySQL, cron, and email delivery

A site may appear to load correctly, while some functions may still work improperly because of PHP settings, the database, or background tasks.

For PHP, check the following:

The active version;
Required extensions;
Memory and upload limits;
The time zone;
Error handling;
PHP-FPM operation, if it is used.

For the database, verify the connection, read and write operations, and correct character encoding. It is useful to create a test record through the site and confirm that it appears in the new database.

Cron jobs are not always migrated together with the files. They need to be recreated on the VPS, and you should verify the paths to PHP and the scripts, the user account that runs them, and error output.

Email delivery should also be tested separately. Depending on the project, the site may use a local mail server, an SMTP provider, or a mail service API. Check the following:

Emails sent from forms;
Password recovery;
Order notifications;
The sender address;
Whether emails land in spam;
SPF, DKIM, and DMARC.

During testing, it is important to prevent real notifications from being sent to customers or production tasks from being run again. Test payments, mailings, and cron jobs are best executed in a safe mode.

Once the pages, forms, database, background tasks, and email have been checked, you can proceed to the SEO audit of the new copy before switching DNS.

Pre-Migration SEO Audit

Preserving the URL Structure

The safest migration option is to move the site to a VPS without changing the domain or page URLs. In that case, search engines continue to see the same URLs; only the server hosting them changes.

Before switching over, compare the following:

The homepage URL;
Categories and product pages;
Articles and archives;
Pagination pages;
URLs with filters and parameters;
Image and document URLs;
Versions with and without www;
HTTP and HTTPS variants.

It is especially important not to lose trailing slashes, letter case, or the nested path structure. Users may not notice these differences, but the server and search engines may treat the URLs as different.

If some URLs do change, the old pages must not simply be deleted. Permanent redirects need to be prepared for them in advance.

Checking 301 Redirects

A 301 redirect tells browsers and search engines that a page has permanently moved to a new address. It is used when changing the URL structure, protocol, primary domain, or www/non-www version.

For each important old URL, there should be one clear route to the current page. Chains like: old URL → intermediate URL → new URL

are best avoided. They increase response time and make it harder for search engine crawlers to process the site.

You should also eliminate loops where two pages redirect to each other.

It is worth checking not only individual rules but also common scenarios:

HTTP → HTTPS;
www → non-www, or vice versa;
old section → new section;
deleted page → the closest relevant content;
outdated URLs from the old CMS.

You should not redirect all deleted pages to the homepage. This type of redirect often does not match the content and may be treated as a soft error.

After checking the redirect paths, make sure that canonical tags, robots.txt, and the sitemap do not reference the old site or a test domain.

Canonical, robots.txt, and sitemap

The canonical tag specifies the preferred version of a page. After migration, it should point to the current HTTPS URL of the primary domain.

Check that the canonical tag:

Does not contain a temporary domain;
Does not point to the old hosting environment;
Uses the correct version, with or without www;
Matches the current URL;
Does not point to a page that returns a redirect or an error.

The robots.txt file must not accidentally block the site from being crawled. In the test version, the following directive is often used: Disallow: /

Before launch, it must be removed or replaced with the production configuration.

In robots.txt, it is also advisable to check the link to the sitemap: Sitemap: https://example.com/sitemap.xml

The sitemap.xml file itself must contain current URLs, be accessible with a 200 status code, and exclude test URLs, redirects, and pages marked with noindex.

After checking these signals, the remaining step is to review the actual server responses and internal navigation.

Checking response codes and internal links

Key pages should return the correct HTTP status codes:

Situation	Expected code
Live page	200
Permanent redirect	301
Temporary redirect	302 or 307
Removed page	404 or 410
Server error	500 and other 5xx codes

After a migration, it is especially important to identify pages that have unexpectedly started returning 404, 403, or 500.

Internal links should point directly to the final HTTPS URLs rather than go through redirects. You should also check:

Menus;
Links within text content;
Images and documents;
Pagination;
Canonical tags;
Links in the sitemap;
URLs in structured data.

For a large site, manual checks are not enough. It is better to run a crawler and compare the results for the old and new versions: the number of URLs, response codes, redirects, canonical tags, and page depth.

When the URL structure, redirects, canonical tags, robots.txt, sitemap, and internal links match what is expected, you can proceed with switching the domain to the new VPS.

Pointing a Domain to a VPS

Lowering the TTL before migration

TTL determines how long DNS resolvers can keep a record in their cache. The higher the value, the longer some users will continue to access the site using the old IP address after the switch.

24–48 hours before migration, it is best to lower the TTL for the main records, for example to: 300 seconds

This will speed up DNS updates after the IP address changes. If you lower the TTL immediately before the switch, the old value may already be cached, so the effect will not be immediate.

Only the records associated with the site need to be changed: typically A, AAAA, and sometimes CNAME records. Mail-related MX, SPF, DKIM, and DMARC records should not be touched unless necessary.

After the migration is complete and the site has stabilized, the TTL can be restored to its normal value, such as 3600 seconds or higher.

Once the reduced TTL value has had time to propagate, you can update the DNS records.

Changing DNS Records

To migrate a website, it is usually enough to replace the IP address in the A record for the primary domain. If www is used, check the separate record or CNAME as well.

A typical setup looks like this:

Record	What to change
A for example.com	Specify the IPv4 address of the new VPS
AAAA for example.com	Specify a valid IPv6 address for the VPS or remove the old record
www	Update the A record or keep a valid CNAME
MX	Do not change it if email remains with the current provider
TXT	Keep SPF, DKIM, DMARC, and verification records

It is especially important to check the AAAA record. If the old IPv6 record continues to point to the previous server, some visitors will reach the old version of the site even if the A record is correct.

Do not change the NS servers and the site IP address at the same time unless necessary. A full DNS zone migration increases the risk of losing mail and service records.

After saving the changes, check which IP address is returned by different DNS servers.

Checking DNS propagation

DNS updates do not take effect instantly. Some resolvers will start returning the new IP address within a few minutes, while others may continue using the old record until the cached TTL expires.

You can check the current response with the following commands:

nslookup example.com

dig example.com A

For IPv6: dig example.com AAAA

It is useful to compare responses from several public DNS servers and to check the domain from different networks: a home internet connection, a mobile connection, and an external service.

At the same time, monitor the logs on the new VPS. If real requests to the primary domain appear in the access log, some traffic has already reached the new environment.

After the switch, check the following:

Primary domain and www;
HTTP and HTTPS;
IPv4 and IPv6;
Certificate;
Redirects;
Forms and authentication;
Email sending;
High-traffic pages.

While DNS is propagating, visitors may reach both servers. For this reason, the old hosting environment must remain operational.

Old hosting during the cutover

Do not shut down the old environment immediately after changing DNS. Some users, search engine crawlers, and external services will continue to access the old IP address for some time.

It is best to keep the old site available for at least a few days. This is usually enough for projects with infrequent updates, but an active store or service requires additional data synchronization.

The main issue during the transition period is that changes can be split between two environments. For example, an order may be written to the old database while another user is already working with the new one.

To avoid data loss, you can:

Briefly enable maintenance mode on the old site;
Disable new orders or posts while the final dump is being created;
Perform the final database synchronization before the DNS cutover;
Leave the old version in read-only mode;
Check webhooks and background jobs to ensure they are not running on both servers at the same time.

On the old hosting environment, you should also avoid immediately deleting files, the database, SSL, or mail settings. They will be useful for a quick rollback if a critical issue is found on the VPS.

When different networks consistently return the new IP address, the site passes functional checks, and requests stop reaching the old server, you can proceed to post-migration site verification.

Post-migration website verification

Site operation over HTTP and HTTPS

After switching DNS, check that the site opens on the primary domain and on all expected address variants:

http://example.com;
https://example.com;
http://www.example.com;
https://www.example.com.

One variant should be chosen as the primary one, and the others should redirect to it with a permanent 301 redirect.

HTTPS should work without browser warnings. Check the following:

Certificate validity period;
Domain match;
Support for www, if it is used;
Correct certificate chain;
No mixed content;
Automatic certificate renewal.

It is useful to open the site not only in a regular browser window, but also in a private window or from another device. The local DNS cache and saved redirects can sometimes hide real issues.

If the site is available through all required address variants, you can proceed to checking redirects and canonical tags.

Checking redirects and canonical tags

After migration, make sure that old and alternative URLs point to the correct pages, not to the homepage or an error page.

It is especially important to check:

HTTP → HTTPS;
www → non-www, or vice versa;
Old URLs → new pages;
URLs with and without a trailing slash;
Pages after a structure change;
Redirects from .htaccess or the Nginx configuration.

A redirect should lead directly to the final URL without unnecessary intermediate steps. Redirect chains and loops make the site harder to crawl and increase response time.

The canonical tag on each important page should point to the current HTTPS URL on the primary domain. It must not contain a temporary subdomain, an old IP address, or a URL that redirects.

After SEO signals, you need to check the functions that create or transmit data.

Forms, email, uploads, and background tasks

Even if the pages load, some functionality may not work because of permissions, SMTP settings, cron jobs, or changed paths.

After the migration, you should recheck the following:

Contact forms;
Registration and login;
Password recovery;
Checkout;
Payments and webhooks;
Image and document uploads;
Sending system emails;
Cron jobs;
Queues and background processes;
External APIs and integrations.

For each form, make sure that data is not only submitted but also saved to the new database, appears in the admin panel, and triggers the required notifications.

Email should be tested from both angles: whether messages reach the recipient and whether they end up in spam. If the site sends email through SMTP, make sure the username, password, port, and sender address were migrated correctly.

Cron jobs and background tasks must not run on both the old hosting environment and the new VPS at the same time. Otherwise, you may get duplicate emails, repeated charges, duplicate order processing, or conflicting imports.

If functionality is unstable, the easiest place to find the cause is usually the logs.

Web Server Logs and Application Errors

During the first hours and days after migration, logs should be reviewed more frequently than usual. They help identify errors that are not visible on the homepage.

For the web server, two types of logs are important:

access log — which URLs users and search engine crawlers request;
error log — configuration, PHP, permission, and application connection errors.

You should also check the following separately:

PHP-FPM;
System log;
Database logs;
CMS or application logs;
cron;
Mail service;
Task queue.

Pay special attention to:

An increase in 404 responses;
500, 502, 503, and 504 errors;
Database connection issues;
Permission denied;
Insufficient memory;
Disk space exhaustion;
Recurring cron errors;
Requests to old paths and the test domain.

Log checks should continue not only immediately after the migration, but also for several days afterward. Some errors appear only in rare scenarios, under high load, or during the next run of a background task.

If the site is running reliably, features are working, and the logs show no new critical errors, you can proceed to the post-migration SEO check.

Post-Migration SEO Checklist

robots.txt and sitemap.xml

After switching DNS, recheck robots.txt on the production domain. Test versions often block all crawling, and if that setting is accidentally left in place, search engine crawlers will stop crawling the site.

Make sure that:

The file is accessible at https://example.com/robots.txt;
Important sections are not blocked from crawling;
System directories are blocked correctly;
The file does not contain links to the temporary domain;
The current sitemap URL is specified.

The sitemap line must point to a working HTTPS address: Sitemap: https://example.com/sitemap.xml

The sitemap must return a 200 status code and contain only current canonical URLs. It must not include test URLs, pages with redirects, noindex directives, or errors.

After checking the files, you can move on to webmaster tools.

Google Search Console and Bing Webmaster Tools

If the domain has not changed, you usually do not need to create the property again. However, after the migration, you should verify that ownership verification is still in place and that data is still coming in.

In Google Search Console and Bing Webmaster Tools, you should:

Check that the property is accessible;
Resubmit the current sitemap.xml;
Test several key URLs;
Check for crawl errors;

Make sure robots.txt is not blocking important pages;
Review any messages about HTTPS and mobile version issues.

If an HTML file or meta tag was used for verification, it may have been lost during the migration. DNS verification usually survives a migration as long as the TXT record remains in the DNS zone.

After submitting the sitemap and checking key pages, you should monitor how search engines crawl the site.

Checking Indexing and Crawl Errors

Temporary fluctuations may occur in the first few days after the migration, but widespread errors require a quick response.

It is especially important to monitor:

An increase in 404 errors;
5xx errors;
Pages blocked by robots.txt;
URLs with an unexpected noindex directive;
Incorrect canonical tags;
Redirect chains and loops;
Duplicates across HTTP, HTTPS, www, and non-www versions;
A decrease in the number of successfully indexed pages.

For important URLs, you can use URL inspection in Search Console. It is also useful to run another technical crawl of the site and compare it with the pre-migration results.

If old URLs have started dropping out of the index, check whether they are accessible, whether they lead to relevant pages, and whether the canonical tags or internal links have changed.

Once the technical aspects of indexing are in order, the next step is to check how the migration has affected the site’s actual performance metrics.

Monitoring Traffic and Rankings

After the migration, metrics should be compared with the pre-migration period, taking into account the day of the week, seasonality, and normal fluctuations in demand.

The first metrics to monitor are:

Organic traffic;
Rankings for key search queries;
Number of indexed pages;
Clicks and impressions in Search Console;
Share of 404 and 5xx errors;
Page load speed;
Conversions and revenue;
Traffic share for the main landing pages.

Minor fluctuations may occur even after a correctly executed migration. A sharp and sustained decline should be a concern, especially if it coincides with an increase in crawl errors or a change in the number of indexable URLs.

If traffic drops, it is best to troubleshoot in sequence: site availability, response codes, robots.txt, canonical tags, sitemap, redirects, internal links, and only then external factors.

SEO monitoring should continue for at least several weeks. After that, you can more confidently assess whether the migration was completed without losses and whether the old platform can be shut down permanently.

Common Mistakes When Migrating a Website to a VPS

Changing DNS without a test run

Pointing a domain to a new VPS before testing the site is one of the riskiest mistakes. In this scenario, issues with PHP, the database, permissions, SSL, or the web server configuration are discovered by real users and search engine crawlers.

Before changing DNS, open the site using the hosts file or a temporary domain and check the key pages, forms, authentication, uploads, cron jobs, and email sending.

A test run does not guarantee that there will be no errors, but it helps eliminate the most obvious issues before the new server starts handling production traffic.

Even a fully functional site can lose rankings if its SEO signals change during migration.

Losing canonical tags and 301 redirects

When changing the web server, rules from .htaccess are not always migrated automatically. This is especially common when moving from Apache to Nginx.

As a result, old URLs may start returning 404 errors, while HTTP, HTTPS, www, and non-www versions may become accessible as separate pages.

Before migration, save the current rules and check:

301 redirects from old URLs;
A single canonical domain version;
HTTP-to-HTTPS redirection;
Canonical tags on key pages;
No redirect chains or loops;
Consistency of URLs in the sitemap and internal links.

If an old URL no longer exists, it should lead to a relevant new page rather than being automatically redirected to the homepage.

SEO signals are not limited to the website itself: DNS changes can easily affect other services on the domain as well.

Forgetting about domain email

A DNS zone can simultaneously support a website, corporate email, subdomains, service verification, and anti-spam settings.

If you replace the entire zone during the migration or accidentally delete MX, SPF, DKIM, and DMARC records, the website will continue to work, but emails will stop arriving or start landing in spam.

Before making changes, you need to save all DNS records. If email remains with the previous provider, its records do not need to be changed — simply update the website’s IP address.

After the switch, you should check incoming and outgoing email, contact forms, password recovery, and order notifications.

However, even correctly configured DNS and email will not help restore data if the migration was performed without an up-to-date backup.

Migrating a site without a recent backup

An old archive may not include the latest orders, registrations, posts, or user files. The more active the site is, the faster that copy becomes outdated.

Before the final migration, you need:

A recent archive of the files;
An up-to-date database dump;
A copy of the configuration;
Saved DNS records;
Redirect rules;
Information about cron jobs and integrations.

For a dynamic site, the main migration can be done in advance; immediately before switching over, freeze changes, run a final synchronization, and only then update DNS.

The backup should be stored separately from both servers. If the copy exists only on the old hosting account, it may disappear along with the account or be damaged by the same error.

After a technically successful migration, one more risk area remains: search indexing.

Not checking indexing after migration

The site may appear to work normally, while search engines encounter a blocked robots.txt file, an incorrect noindex directive, an invalid canonical tag, or large numbers of 404 and 5xx responses.

After migration, you should check:

Reports in Google Search Console and Bing Webmaster Tools;
Accessibility of robots.txt and sitemap.xml;
Indexing of key pages;
Increase in crawl errors;
Canonical URLs selected by search engines;
Clicks, impressions, and rankings;
Organic traffic to the main landing pages.

Minor fluctuations are possible, but a sharp, sustained drop usually requires a technical check. The sooner an issue is detected, the fewer pages will have time to drop out of the index.

A safe migration does not end when DNS is changed, but only after the site is operating reliably, search crawlers are receiving correct responses, and traffic and rankings are not showing an abnormal decline.

Step-by-step migration checklist

Before switching the domain, make sure that:

An inventory of files, the database, cron jobs, SSL, email, and DNS has been completed;
The PHP, MySQL, and extension versions are compatible;
A fresh backup of the files and database has been created;
The VPS has been prepared and tested;
The files and database have been migrated;
Configuration and paths have been updated;
File and directory permissions have been configured;
The site has been tested via the hosts file or a temporary domain;
Forms, authentication, email, uploads, and cron jobs are working;
The URL structure has been preserved;
301 redirects, canonical tags, robots.txt, and the sitemap have been checked;
TTL has been lowered in advance;
DNS records have been updated without losing MX, SPF, DKIM, or DMARC records;
The site is accessible over HTTP and HTTPS;
The old hosting continues to run during the transition period;
Search Console and Bing Webmaster Tools show no critical errors;
Traffic, rankings, and indexing are monitored after the migration.

You should disable the old hosting only after DNS has fully propagated, the new VPS is running reliably, and the old server is no longer receiving significant traffic.

Conclusion

A website can be migrated from shared hosting to a VPS without losing traffic or rankings if the migration is divided into preparation, testing, cutover, and follow-up monitoring.

The key rule is not to change DNS until the website has been fully tested on the new server. Before the cutover, you should verify PHP and database compatibility, migrate files and data, and check forms, email, SSL, redirects, and SEO settings.

It is especially important to preserve the URL structure, canonical tags, robots.txt, the sitemap, and 301 redirects. If the domain and page URLs do not change, search engines usually treat the move as an infrastructure change rather than a new website.

The work does not end after the cutover. You need to monitor logs, crawl errors, indexing, traffic, and rankings, while keeping the old hosting available for some time.

A safe migration is not a quick file copy, but a controlled process with a backup, a test launch, and a rollback option. This approach reduces the risk of downtime, data loss, and a drop in search traffic.

FAQ

How long does it take to migrate a website to a VPS?

Copying a small website can take anywhere from about half an hour to several hours. However, a full migration includes preparing the VPS, performing a test run, completing the final database synchronization, switching DNS, and monitoring the site afterward.

For a small project, you should typically plan for one business day. Migrating an online store, portal, or website with a large volume of data may take several days.

Will the website be unavailable during the DNS change?

Not necessarily. If the new VPS is configured and tested in advance, and the old hosting environment remains operational, most users will not notice the switch.

During the transition period, some visitors may still reach the old server, while others will already be routed to the new one. Therefore, both environments must remain available, and for a dynamic website you need to prevent discrepancies in orders, registrations, and other data.

Do you need to change URLs when moving to a VPS?

No. Moving to another server does not in itself require changing the domain or URL structure.

It is safer to keep the existing page URLs, internal links, and canonical tags. If the URLs do change, configure a permanent 301 redirect from each old URL to the relevant new page. Google specifically treats a hosting change without URL changes as a simpler migration scenario.

When can you disable the old hosting?

You can disable the old environment after:

DNS consistently returns the IP address of the new VPS;
The old server is receiving almost no requests;
The website, forms, email, and background tasks are working;
A recent backup has been saved separately;
There are no critical errors in the logs or webmaster tools;
Rollback is no longer required.

In practice, it is best to keep the old hosting active for at least a few days after the cutover.

What should you do if traffic drops after a site migration?

Start by checking for technical causes:

Site availability and response time;
404 and 5xx errors;
robots.txt and noindex;
canonical;
301 redirects;
sitemap.xml;
Internal links;
HTTP/HTTPS and www variants;
Search Console reports.

Minor fluctuations are possible, but a sharp drop is usually related to availability, indexing, or URL changes. In Search Console, you can check page status, sitemap errors, and trends in clicks and impressions.

Sources

1. Google Search Central — Changing Your Web Hosting and SEO

2. Google Search Central — Redirects and Google Search

3. Google Search Console Help — Sitemaps report

4. Cloudflare DNS Documentation — Time to Live