A practical restore checklist for checking your files, database and essential website functions in an isolated environment.

A backup notification tells you that a backup job finished. It does not tell you whether you can recover a working website from that backup.

The missing database table, unreadable archive or unavailable plugin usually becomes obvious during a restore—not while looking at a green status indicator.

A restore test gives you a chance to find those problems while your public website is still running normally.

This guide explains how to test a WordPress backup in a separate environment, check the recovered site and document what would still be needed during a real incident.

1. Identify exactly what your backup contains

A typical WordPress recovery needs both website files and a database.

Files include themes, plugins, uploads and configuration. The database contains posts, pages, settings and other application data. Downloading the WordPress folder alone does not normally capture the database.

Check that your backup includes:

• A database export or recoverable database snapshot.
• Themes, plugins and uploaded media.
• Configuration files needed for recovery.
• A clearly recorded backup date and time.
• Instructions for accessing or downloading the backup.

Keep the files and database associated with the same recovery point. A recent database combined with much older uploads can leave references to media that was never restored.

The WordPress backup handbook explains why both files and the database are needed:

https://developer.wordpress.org/advanced-administration/security/backup/

2. Prepare an isolated destination before restoring anything

Use a separate staging environment or local development environment.

Give it its own document root, database and database user. Confirm that its database credentials cannot write to your production database.

Before importing the backup:

• Protect the destination with authentication or private network access.
• Prevent the restored application from sending real customer emails.
• Block or disable production webhooks and external integrations.
• Prevent live payment requests and automated subscription activity.
• Pause scheduled jobs until you have reviewed what they do.

Apply these controls before the copied application starts running. A restored database may contain live API credentials and scheduled tasks.

A search-engine “noindex” setting can help with search visibility, but it does not protect private customer data. Keep the test environment access-controlled.

Your production DNS records and live website should stay unchanged throughout this exercise.

3. Restore into the test environment

Follow the restore process documented by your backup tool or hosting provider. Confirm the destination again before approving any import or overwrite.

For a manual recovery, the work generally includes restoring the files, importing the database into a separate database and updating the test copy’s configuration.

Check:

• The database import completed successfully.
• The test installation uses the intended database.
• Required files and uploads are present.
• The PHP version and required extensions are compatible.
• The restored site can connect to its database.

If you are importing a database export manually, consult the WordPress database backup and restore instructions. The steps depend on the export format and database tools available:

https://developer.wordpress.org/advanced-administration/security/backup/database/

Do not use a production database as the destination for a practice restore.

4. Check whether the restored site points back to production

A restored database can still contain the public website’s original URLs.

This may cause the test copy to redirect to production or load images and other assets from the live site. That can make a broken restore appear healthy.

Use your browser’s address bar and network tools to check where pages and assets are actually loading from.

If the test copy uses a different hostname, use your backup tool’s URL-handling process or a WordPress-aware replacement method.

WP-CLI provides a search-and-replace command that handles serialized data and supports a dry run. Preview changes and verify the target installation before making replacements.

Official WP-CLI documentation:

https://developer.wordpress.org/cli/commands/search-replace/

Confirm that the test site is displaying its own restored content.

5. Test the functions that matter to your website

Choose checks based on what visitors actually do.

For a business website, this might include:

• Opening important service and contact pages.
• Loading older and recently uploaded images.
• Signing into the WordPress dashboard.
• Searching for a known post.
• Submitting a contact form to a controlled test inbox.
• Checking a representative custom feature.

Compare the recovered content against the backup timestamp. A post created after the snapshot will not normally be present in that snapshot.

For a WooCommerce store, also test product pages, cart behaviour, shipping calculations, taxes and checkout using sandbox payment settings. Route test emails to a controlled destination.

WooCommerce recommends testing important store workflows in staging before affecting customers. Its staging guidance provides a useful workflow checklist:

https://woocommerce.com/document/how-to-update-woocommerce/

Keep staging isolated even if you only intend to browse the restored store.

6. Record recovery time and the potential data gap

Write down when you started the restore and when the recovered website passed your essential checks.

Include time spent:

• Finding the correct backup.
• Obtaining access or downloading files.
• Restoring the database and files.
• Correcting configuration.
• Testing important functions.

Also record the difference between the backup timestamp and the time of the imagined incident.

For example, a snapshot taken at 02:00 will not automatically contain an order placed at 11:00. This is an illustrative scenario, not a measured Webiost customer result.

For an active store, recovering files is only part of recovery planning. Recent orders, payments and inventory changes may need reconciliation before an older database can safely replace production.

7. Keep a short restore-test record

A simple record makes the next test easier:

Website: Test date: Backup timestamp and timezone: Backup location: Restore destination: Restore start time: Essential checks completed at:

Files and media: PASS / FAIL Database connection: PASS / FAIL Administrator login: PASS / FAIL Important pages: PASS / FAIL Forms and controlled email delivery: PASS / FAIL Sandbox checkout, if applicable: PASS / FAIL

Missing data or files: Configuration changes required: Unresolved problems: Person responsible for follow-up:

Record the problems as well as the successful checks. Someone else should be able to understand what happened without repeating the entire investigation.

8. Close the test environment properly

When testing is complete, remove the temporary environment if you no longer need it. If you retain it, keep access restrictions, updates and integration controls in place.

Remove temporary database dumps, archives and credentials from publicly accessible locations.

Repeat the exercise after meaningful changes to your hosting, backup process or website functionality, and choose an ongoing schedule that reflects how frequently your data changes.

If you are comparing hosting services, ask about backup retention, restore access, recovery assistance and exclusions. The Webiost shared hosting page describes its backup features alongside plan information:

https://webiost.com/hosting/shared-hosting

A useful restore test ends with a working recovered website, a record of what was checked and a clear list of anything that still needs fixing.

Published by Webiost — Practical WordPress and Hosting Guides.

But there's a catch.

Your website might load perfectly on your computer while visitors in another location still reach the old server. Your SSL certificate might work on the homepage but fail on the www version. Or an old product URL might suddenly lead to a 404 page.

These problems are easy to miss if you only check whether the homepage loads.

Here is a practical way to verify the three things that often cause trouble after a WordPress migration: DNS, SSL and redirects.

1. Start by Checking Where Your Domain Points

DNS tells browsers which server should handle requests for your domain.

After a migration, you want to confirm that the domain resolves to the intended destination.

On macOS or Linux, open a terminal and run:

dig +short example.com A
dig +short example.com AAAA
dig +short www.example.com CNAME

Replace example.com with your own domain.

Check the returned IPv4 and IPv6 records against your hosting provider's configuration. If you use Cloudflare or another reverse proxy, the returned addresses may belong to the proxy rather than your hosting server. That's expected when the proxy is enabled.

To see which nameservers are authoritative for your domain:

dig +short example.com NS

You can also query a public resolver:

dig @1.1.1.1 +short example.com A

If you use Windows, nslookup provides a simple alternative:

nslookup example.com

What are you looking for?

The domain should resolve according to your intended DNS setup. Unexpected addresses, outdated IPv6 records or incorrect nameservers deserve investigation.

Remember that cached DNS responses can remain visible for a while. Different resolvers may return different results during a cutover.

2. Test the New Server Before Public DNS Changes

If you still haven't switched DNS, you can test a destination server directly without modifying your computer's hosts file.

For example:

curl --resolve example.com:443:203.0.113.10 -I https://example.com/

In this example, 203.0.113.10 is a documentation-only IP address. Replace it with your actual destination server's public IP.

The command tells cURL to connect to that IP while requesting the domain over HTTPS.

This is useful for checking whether the destination server is configured to serve the correct website and certificate.

It does not guarantee that the entire WordPress application works, so continue with functional checks.

Important: Do not disable TLS certificate verification just to make a failed test pass. A certificate mismatch is something to investigate, not hide.

3. Verify HTTPS on Every Important Hostname

A website can have a valid certificate for example.com and still have a problem with www.example.com.

Start by checking both versions:

curl -I https://example.com/
curl -I https://www.example.com/

Depending on your chosen canonical hostname, one version may redirect to the other.

Check the complete redirect sequence:

curl -IL --max-redirs 5 http://example.com/

You want the request to reach the intended HTTPS destination without an unnecessary chain or loop.

Also open the website in a browser and check:

• The SSL certificate is valid for the hostname.
• The browser doesn't report a certificate error.
• Images, scripts and stylesheets load over HTTPS.
• Important forms and login pages work securely.

If you use a CDN or reverse proxy, remember that HTTPS configuration may exist in more than one place.

A redirect loop can happen when the proxy and the origin server disagree about whether a request is already using HTTPS.

4. Confirm WordPress Is Using the Correct URLs

WordPress stores important website addresses in its configuration.

If WP-CLI is available, you can inspect them without changing anything:

wp option get home
wp option get siteurl

The home option typically represents the public site address, while siteurl identifies the WordPress installation address.

For a standard WordPress installation, you would normally expect these values to match your intended setup.

They do not always need to be identical. WordPress can legitimately be installed in a subdirectory.

If you've changed domains, review database URLs carefully.

WordPress content and plugin settings can contain serialized data, so performing a careless SQL text replacement can damage configuration.

Use migration-aware tooling and test replacements before making database changes.

Do not run write operations against production without a verified backup and rollback plan.

5. Check Redirects Beyond the Homepage

Here's a common migration mistake:

The homepage works, so everyone assumes the redirects work too.

But Google, customers and other websites may still link to older URLs.

Create a small list of important pages, such as:

• /about/
• /contact/
• /services/
• /blog/
• /shop/
• Popular product or service pages

Test each URL.

For example:

curl -IL --max-redirs 5 https://example.com/old-page/

If the page has permanently moved, a 301 or 308 redirect may be appropriate.

The redirect should lead to the most relevant replacement page—not automatically send every old URL to the homepage.

Watch for:

Redirect loops: The browser keeps bouncing between two URLs.

Redirect chains: A request passes through several unnecessary destinations.

Unexpected 404s: Old URLs no longer exist and have no appropriate replacement.

HTTP/HTTPS inconsistencies: Different versions of a URL lead to unexpected locations.

Remember that some applications do not support HTTP HEAD requests correctly. If curl -I behaves differently from a browser, repeat the test using a normal GET request before diagnosing a fault.

6. Check SEO Signals After the Migration

Even when visitors can use the website, search engines may receive conflicting signals.

Inspect a few important pages and verify:

Canonical URLs: Does each page identify the intended canonical address?

Robots directives: Was a temporary staging noindex accidentally left enabled?

Internal links: Do links point to the current URLs?

Sitemap: Does it contain the correct indexable pages?

Redirects: Do old URLs resolve to appropriate destinations?

For domain or URL changes, Google's official site-migration documentation recommends mapping old URLs to new ones and monitoring the process through Google Search Console.

If you're simply moving hosting providers without changing public URLs, the main goal is keeping those URLs available and stable.

A server migration shouldn't accidentally become a website-wide URL migration.

7. Don't Forget the Real Customer Experience

Technical checks are important, but they aren't the end of the process.

A successful migration should preserve the functionality your visitors rely on.

Before signing off, test:

• Contact forms
• WordPress login
• WooCommerce checkout, if applicable
• Account registration and password resets
• Transactional email delivery
• Scheduled tasks
• Image and file uploads
• Important third-party integrations

For stores and booking websites, use test transactions or safe staging environments rather than placing unnecessary live orders.

Keep an eye on application logs and customer support reports after the cutover.

Sometimes the first sign of a migration problem is not a server error. It's a customer saying they never received their confirmation email.

A Simple Post-Migration Checklist

Before considering the migration complete, confirm that:

• DNS points to the intended infrastructure.
• IPv4 and IPv6 records have been checked.
• SSL certificates work for the required hostnames.
• HTTP redirects to the intended HTTPS URL.
• WordPress home and site URLs are correct.
• Important pages return the expected responses.
• Old URLs redirect to relevant destinations where appropriate.
• Canonical URLs and indexing directives are correct.
• Forms, email and critical customer workflows work.
• Backups and a rollback procedure remain available.

Final Thoughts

A WordPress migration isn't successful simply because the website loads.

It's successful when the domain resolves correctly, HTTPS works, important URLs remain accessible and customers can continue using the website without unexpected interruptions.

The most useful migration checklist is one your team can actually follow and verify—not just a document that says everything should be fine.

For more structured migration preparation, see the Webiost WordPress Migration Preflight & Rollback Toolkit. It includes practical checklists and troubleshooting guidance.

Further Reading

• WordPress Official Migration Handbook
• WP-CLI Option Commands
• Google Search Central — Site Moves

Published by Webiost — Practical WordPress, Hosting & Infrastructure Guides