Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
A VPS snapshot clone usually contains the same WordPress files and database as the original server, but it can also retain the old domain, URL settings, virtual-host assumptions, credentials, and file ownership. Restore access in this order: point DNS at the clone, confirm the web server routes the hostname to the intended document root, verify the database settings, correct WordPress URLs, repair permissions, restore rewrite rules, then check HTTPS and caches. Changing database values before traffic reaches the clone can make a correct fix appear ineffective.
Start with the shortest safe diagnosis
Do not begin by repeatedly editing the database. First prove that a browser request for the hostname reaches the cloned VPS and that the web server serves the cloned WordPress directory. Then work inward toward PHP, the database, and WordPress settings.
Recommended Free Tools
- Confirm DNS: Check the domain’s A and AAAA records and verify that they resolve to the clone’s public IPv4 or IPv6 address. Test from a resolver outside your local network if possible.
- Confirm web-server routing: Inspect the Apache virtual host or Nginx server block for the exact hostname. Its document root must contain the intended
wp-admin,wp-content, andwp-includesdirectories. - Check database access: Compare
DB_NAME,DB_USER,DB_PASSWORD,DB_HOST, and the table prefix inwp-config.phpwith the database and user actually present on the clone. - Correct the site URL: Update the
siteurlandhomevalues when the domain, scheme, or path changed. - Repair links and permissions: Use a serialization-aware search-and-replace method, then fix ownership, modes, and rewrite rules.
- Check TLS and caches: Make sure the requested hostname has a certificate and that old redirect responses are not being served from a cache.
Keep the original snapshot and a current off-site database backup untouched while you work. WordPress recommends a current backup before changing server configuration or database values, and a rollback is valuable if an edit locks you out.
What a cloned snapshot preserves—and why that causes trouble
A snapshot is a copy, not a fresh WordPress installation. It commonly preserves the source server’s database, wp-config.php, web-server configuration, SSL redirect rules, cron definitions, plugin settings, and file ownership. Those values remain valid only if the clone has the same hostname, path, database service, credentials, and network identity.
#1 Best Overall
- Easily store and access 2TB to content on the go with the Seagate Portable Drive, a USB external hard drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
The most common mismatch is a clone that still believes it is the original site. WordPress may redirect every request to the old domain because wp_options.siteurl and home still contain it. The web server may also have a server block that answers only for the old hostname, while the new hostname falls through to a default site. Treat routing and application configuration as separate layers: both must be correct.
Check DNS, the virtual host, and the document root
Verify the hostname reaches the clone
Use DNS tools or your provider’s control panel to inspect A and AAAA records. The records must point to the clone’s public addresses, not merely to the original VPS. If both record types exist, an IPv6-capable client may use the AAAA record and bypass a correctly configured IPv4 clone. Correct or remove an obsolete record before diagnosing WordPress.
DNS changes can be cached by recursive resolvers. Test with the actual hostname and note the address returned, but do not assume that a local result proves every visitor reaches the clone.
Match the web-server host configuration
In Apache, inspect the virtual host; in Nginx, inspect the server block. The configuration must list the requested domain in its host names and point to the clone’s WordPress document root. A copied configuration may still contain the old name, an old certificate path, or the source directory.
Confirm that the document root contains the files for this site rather than a default welcome page or another virtual host. A request that reaches the wrong directory can produce a normal-looking page while all WordPress fixes are applied to the wrong installation.
Use status codes to separate layers
| Observed result | Most likely layer | First check |
|---|---|---|
| Old domain appears in the address bar | WordPress URL values or server redirect | Compare home, siteurl, and redirect rules |
| “Error establishing a database connection” | Database service, credentials, host, or privileges | Inspect wp-config.php and test the cloned database user |
| Homepage loads but internal links return 404 | Rewrite or permalink configuration | Check .htaccess or Nginx rules and resave permalinks |
| 403 Forbidden or failed uploads | Ownership, permissions, or web-server access | Check directory traversal and file modes |
| Blank response or 500 status | PHP or application error | Read web-server and PHP-FPM logs before changing more settings |
Fix “Error establishing a database connection”
WordPress uses the values in wp-config.php to open its database connection. On a clone, the database server may have a different hostname, the service may not be running, or the copied user may not be allowed to connect from the new machine.
Check every connection value
DB_NAMEmust match the imported database name.DB_USERandDB_PASSWORDmust match a user that exists on the cloned database server.DB_HOSTmust identify the reachable database service; a value that worked on the source may not work on the clone.$table_prefixmust match the prefixes used by the imported tables. A mismatch makes WordPress appear to have no settings even when the connection succeeds.
Check that the database service is running and that the cloned user has privileges from the clone’s host. Do not paste passwords into support tickets or public logs. If you change a credential, update the database grant and wp-config.php together, then test again.
Rank #2
- Easily store and access 5TB of content on the go with the Seagate portable drive, a USB external hard Drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Distinguish a connection failure from an empty database
An explicit database-connection error points to connectivity or credentials. A site that connects but behaves like a new installation can indicate the wrong database name or table prefix. Confirm that the expected WordPress tables and content exist before importing another copy; otherwise you can overwrite the only usable database.
Correct the WordPress domain, scheme, or path
If the clone uses a different domain, HTTPS scheme, or subdirectory, WordPress must be told the new canonical URL. In the database, update the siteurl and home rows in the wp_options table (or the equivalent table name when the prefix differs). Use complete URLs such as https://example.test without a trailing slash.
When the dashboard is inaccessible, temporarily defining these constants in wp-config.php can regain access:
define('WP_HOME', 'https://example.test');
define('WP_SITEURL', 'https://example.test');Place the definitions before the line that says WordPress should stop editing, and remove or replace them after the database values are corrected. A forced HTTPS setting combined with a missing certificate can create a redirect loop, so verify TLS before insisting on HTTPS.
If the site moved into or out of a subdirectory, include that path consistently in the URL and in the web-server document root. A mismatch between the URL path and filesystem path commonly produces redirects to the wrong location or links that omit the required directory.
Replace old-domain references without corrupting data
Changing home and siteurl fixes the canonical address, but old URLs can remain in post content, widgets, theme settings, and plugin options. Those references can break images, scripts, menus, and forms even when the homepage opens.
Use WP-CLI’s serialization-aware search-replace command or a migration tool that understands serialized PHP data. A raw whole-database text replacement can change string lengths without updating serialized length markers, corrupting options and widget data. Run a dry run first when your tooling supports it, review the affected tables, and keep the backup available.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
- Easily store and access 1TB to content on the go with the Seagate Portable Drive, a USB external hard drive.Specific uses: Personal
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop. Reformatting may be required for Mac
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
wp search-replace 'https://old.example' 'https://new.example' --all-tablesAdapt the command to the actual domains and tables, and run it from the WordPress directory with the appropriate account. Do not rewrite post GUID values. GUIDs identify posts for feeds and other integrations; changing them is not a domain migration requirement and can create avoidable downstream changes.
Repair ownership and permissions behind 403s and failed writes
A clone can retain numeric user and group IDs that do not exist on the new VPS. The web-server account may then be unable to traverse the document root, read PHP files, write to wp-content, or create uploads. Files accidentally left at mode 0000 are another documented migration failure.
- Check that the web-server user can traverse every parent directory leading to the document root.
- Confirm that WordPress files are readable by the web server;
0644is a normal file-mode example. - Ensure directories, especially
wp-content/uploads, have the access needed for uploads without making the whole site writable. - Correct ownership to the account used by the web server or the deployment model used on the clone.
Apply the least access necessary. Broadly making every file writable can hide the immediate 403 while creating a security problem. After correcting access, test the homepage, log in, upload a small image, and save a harmless setting.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Restore permalinks and rewrite rules when only links fail
WordPress generates friendly URLs through Apache rewrite rules or Nginx configuration. A homepage can load directly while every post or page returns 404 when those rules were not copied, the required Apache module is inactive, or the server block points to a different root.
Apache
Check that the document root permits the site’s .htaccess rules and that the WordPress rewrite configuration is present. After the URL and document root are correct, open the WordPress dashboard and use Settings > Permalinks, then select the existing structure and choose Save Changes. This regenerates the standard rules without requiring a new permalink choice.
Nginx
Nginx does not process .htaccess. Its server block must pass unknown paths to the WordPress front controller, normally index.php, and PHP-FPM must be reachable. Check the active configuration rather than an unused copied file, then reload the service using your normal administration procedure.
Test a known post, a category, a media URL, and the login URL separately. If only media fails, return to the uploads path and permissions rather than changing rewrite rules again.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Rank #4
- Easily store and access 4TB of content on the go with the Seagate Portable Drive, a USB external hard drive.Specific uses: Personal
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Check HTTPS, redirects, and caches
The clone needs a certificate valid for the hostname visitors request. A certificate for the old domain, an HTTP-to-HTTPS rule copied from the source, or a hard-coded old hostname can cause certificate warnings or redirect loops.
Inspect redirects with a browser’s network panel or an HTTP-header tool. Confirm that each redirect remains on the new hostname and ends at the intended scheme. Check both HTTP and HTTPS, and test an incognito window after the server response is correct.
Purge page, object, CDN, and browser caches only after confirming that requests reach the clone. Cached redirects can preserve the old destination and make a fixed server appear broken. If a cache is outside your control, lower its influence by testing from an uncached path or another network while you wait for expiry.
Collect evidence before escalating
When the basic checks do not isolate the fault, gather facts rather than making more edits. WordPress Site Health can export the WordPress version, PHP and server details, database information, active plugins and themes, and permissions-related details. Save that export with the time of the incident.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitches- Web-server error and access logs covering a failed request.
- PHP-FPM or PHP error logs, including the exact timestamp.
- DNS answers for A and AAAA records.
- HTTP status codes and redirect destinations for the homepage, login page, and a known post.
- The exact browser error, including whether it is a certificate warning, timeout, 403, 404, 500, or database message.
Redact passwords, salts, private keys, and personal data before sharing configuration or logs. The combination of a timestamp, requested URL, status code, and server log entry usually identifies which layer still fails.
A safe recovery workflow for common scenarios
The clone redirects to the old domain
- Verify DNS and the matching virtual host first.
- Inspect
homeandsiteurlin the correct prefixed options table. - Use temporary
WP_HOMEandWP_SITEURLconstants if necessary to regain the dashboard. - Search and replace remaining old URLs with a serialization-aware tool.
- Inspect server, plugin, and HTTPS redirect rules for a hard-coded old hostname.
The database error appears immediately
- Confirm the database service is running on the clone.
- Match all five connection values and the table prefix.
- Verify the user exists and is permitted to connect from the clone.
- Check that the selected database contains the expected WordPress tables.
The homepage works but links are 404
- Confirm the document root and hostname are correct.
- Inspect Apache rewrite support or the active Nginx front-controller rule.
- Save the permalink settings once the URL is correct.
- Test a post, category, login page, and media file to identify whether the problem is global or limited to uploads.
The site returns 403 or cannot upload
- Check ownership and traversal permissions on the document root.
- Find files left at
0000or otherwise unreadable. - Use
0644as the normal file-mode example for files and grant directory write access only where WordPress needs it. - Review web-server access rules and test an upload after the correction.
Validate the clone before retiring the original
Do not delete the source snapshot when the homepage first appears. Test the front end, administrator login, media upload, several permalink types, scheduled tasks (cron), plugin and theme functionality, HTTPS, and redirects. Confirm that forms and integrations use the new hostname where applicable.
Keep the original snapshot and an off-site database backup until these checks pass and you have a rollback plan. A clone is ready to become the production server only when traffic, application settings, filesystem access, and background jobs all agree on the same domain and paths.
Quick Recap
Prevention checklist for the next snapshot
- Record the source domain, scheme, document root, database name, table prefix, and web-server account before cloning.
- Prepare a current database backup stored off the VPS.
- Document DNS A and AAAA records and the certificate names.
- Plan the hostname and URL changes before the clone receives public traffic.
- Verify ownership and permissions after restoring files.
- Keep a tested snapshot until front-end, login, uploads, permalinks, HTTPS, and cron checks are complete.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
