How to Recover a WordPress Site From the Wayback Machine

Your WordPress site is gone. You open it and there is nothing there. Maybe the hosting account expired. Maybe a migration went wrong. Maybe someone deleted the wrong folder.

So you go looking for the backup. The one that was supposed to run every night. The one everyone assumed was working.

It is not there. It was never made.

This post explains what to do next. It is long because there are real steps, and skipping them is how people end up with a site that is technically back but gets no visitors.

If you read only one section, read Step 1. It tells you in five minutes whether recovery is even possible.

What you have actually lost

Be clear about the damage first. The plan depends on it.

The content. All your posts and pages. This hurts, but content can be written again. It costs time and money, but it is possible.

The URLs. This is the bigger loss. Over the years, other websites linked to your pages. Customers bookmarked them. Those links still exist and still point at your old web addresses. Right now they lead to nothing.

Your position in Google. Google will keep showing your pages for a while. Then it will start removing them, because every time it visits, the page is missing. This does not happen overnight. You have some time, and that is the reason to move fast.

The structure. Publish dates, categories, tags, and the menu. You do not notice these until you try to rebuild without them.

Here is the part most people miss.

If you rebuild the same content at new URLs, you have not recovered your site. You have launched a new site with old writing on it. It gets none of the old links and none of the old ranking. You do all the work of a recovery and get the result of a fresh start.

Everything below is designed to avoid that.

Things people try first that do not work

Ask the host for a backup. Always worth a support ticket. Sometimes the answer is yes. But most hosts only keep backups for a few days, and most people find the problem after that window has closed. If the account was suspended for non-payment, the files may already be deleted.

Google's cache. This used to be the backup plan for everyone. It no longer exists. Google shut down its public cache on 2 February 2024 and removed the cache: search command completely later that year. Any "cache checker" tool you find today is just pulling from a public archive instead. Do not waste time here.

A staging or test site. Check for one. On a subdomain, on an old host, on an agency server. It exists often enough to be worth ten minutes of looking.

What is usually left is the public web archive. The Wayback Machine at archive.org is the best option, because it saved the most pages and you can search its index directly.

Step 0: Stop things getting worse

Do this in the first hour, before any rebuilding.

Renew the domain. If the domain name itself expired, nothing else matters. Check the expiry date and renew it today. If it already expired and someone else bought it, the recovery is over.

Put something at the address. Even a single page saying "we are rebuilding, back soon" is better than nothing. A server that answers is better than a server that refuses to connect.

Send the right status code. Your holding page should return 503, not 200.

Here is what those mean. A 503 tells Google "this is temporary, come back later." A 200 tells Google "this page loaded fine, this is the real content now." If you use 200, you are telling Google that every page on your site is now a page that says "we are rebuilding."

In nginx:

location / {
    return 503;
}
error_page 503 /maintenance.html;

Write down the date it broke. You will want it later.

Step 1: Check what the archive actually saved

This step decides whether the rest is worth doing. Most people skip it and go straight to clicking around on the Wayback Machine calendar.

Clicking around only tells you the homepage was saved. It does not tell you whether your 400 blog posts were saved. That is the real question.

There is a faster way. The Wayback Machine has a list of every URL it saved, and you can search it. Run this in your terminal, replacing the domain:

curl -s "https://web.archive.org/cdx/search/cdx?url=yourdomain.com&matchType=domain&fl=original&collapse=urlkey&filter=statuscode:200" > archive-urls.txt
wc -l archive-urls.txt

That saves one line for every page the archive has a working copy of, then counts them.

Now read the number:

• A few thousand lines, including your blog post URLs - good. This is worth doing
• A few hundred lines, mostly images and theme files - the archive only skimmed your site. You will get the main pages and lose the rest
• Under fifty lines, mostly the homepage - there is not enough here. Rebuilding by hand will be faster
• Nothing - the site cannot be recovered this way. Stop and plan to rewrite

Next, look at what those URLs actually are. This command hides the image and system files so you can see real pages:

grep -v -E "wp-content|wp-includes|feed/|\?" archive-urls.txt | sort -u | head -100

You are checking two things. First, that your actual posts are in the list, not just the homepage. Second, what your URLs looked like, because you will need to copy that exactly in the next step.

Sites that ran for years and had links from other websites are usually saved well. New sites, quiet sites, and sites that blocked bots in robots.txt often are not saved at all.

Keep the archive-urls.txt file. You will use it again at the end to check your work.

Step 2: Set up WordPress correctly before importing

Install a fresh copy of WordPress on the original domain. Two settings matter before you import anything.

Permalink structure. This is the setting that controls what your URLs look like. Look at the URLs from Step 1 and match the pattern:

• /2019/03/post-title/ means Month and name
• /post-title/ means Post name
• /blog/post-title/ means a custom pattern with a prefix

Set this in Settings first. If you import posts and change this afterwards, WordPress changes every URL and you have to redo the work.

Pick http or https, and www or no www. Your old URLs are probably http:// and may or may not have www. Pick one version for the new site and make everything else redirect to it.

Do not install any other plugins yet. A caching plugin or an SEO plugin will change how pages behave and make problems much harder to find.

Step 3: Bring the content back with its structure

Four things need to survive the move. They are not equally easy.

The same URL for each post. This is the most important one. It is the whole reason to recover instead of rewrite. A post restored at /guide-to-x/ receives every old link and keeps its place in Google. The same post at /guide-to-x-2/ receives nothing.

The real publish date. Taken from the archive, not set to today. If eight years of posts all show today's date, your archive pages break, your post order is wrong, and the site looks brand new.

Categories and tags. These create their own pages on your site, and those pages only work if posts are actually assigned to them. Doing this from memory across hundreds of posts is where mistakes pile up.

The menu, including drop-downs. Parent items and child items in the right order. This is what makes the site feel like the one that was there before, instead of a pile of separate pages.

All four are sitting inside the saved pages. The problem is that they are mixed into the old theme's HTML. There is no export file and no simple list to read them from.

Why doing it by hand stops working

For five pages, doing it manually is fine. Open the saved page, copy the text, paste it into WordPress, set the URL and date by hand. Slow, but it works.

For 400 posts it does not work, and the reason is not the typing.

You are also guessing publish dates from whatever the old theme printed on the page. You are remembering which categories each post belonged to. You are deciding, on every single page, which part is the article and which part is the sidebar. You are rebuilding a menu you last saw three years ago.

Around post 120, your accuracy drops. And you cannot see the mistakes. In the WordPress admin everything looks fine. You find out two months later, when the traffic does not come back.

There is a second problem. If you get halfway and realise you have been doing something wrong, you now have to delete and redo work by hand, with no record of what you changed.

Using a tool for the rebuild

WP Wayback Pro reads the saved pages and creates real posts and pages in your WordPress database. It keeps the original URL, the real publish date, the categories, the tags, and the menu with its drop-downs.

Three things about how to use it matter more than the feature list.

Do a dry run first. This runs the whole job and saves nothing. You just read the results. On a big recovery, this is how you catch a problem before 400 wrong posts are in your database instead of after.

Check every item before importing. Reading someone else's theme is never perfect. Some sites are clean and simple. Some wrap the article in six layers of code with meaningless names. So every item shows you what was found and how it was found, and you can fix anything wrong before it gets imported.

Expect to run it more than once. Import some posts, notice something you want done differently, change it, run again. Posts that already exist are skipped, so you do not get post-title-2 copies. Comments are not duplicated. Menus are replaced instead of stacked on top of each other. And if you close your browser, it picks up where it stopped.

The goal is for the second run to be boring. That is what lets you fix things as you go instead of getting one nervous attempt.

You need WordPress 5.8 or newer and PHP 7.4 or newer with the DOM extension. DOM is the part that reads the saved pages. Almost every host has it.

Step 4: Handle the images

Image links are pointed at their original locations, but the image files are not downloaded. Two things can happen.

If the old host is still online, the images will show up, and you can pull them into your media library later with any bulk image importer plugin.

If the old host is gone, check whether the archive saved your images:

curl -s "https://web.archive.org/cdx/search/cdx?url=yourdomain.com/wp-content/uploads*&fl=original&collapse=urlkey&filter=statuscode:200" | wc -l

If that number is high, your images are in the archive and can be downloaded separately. Treat this as its own task on its own day. Mixing it with the content recovery slows both down.

If neither works, the images are gone. Replace them on your most important pages first and leave the rest for later.

Step 5: Check your work

The site being online is not the same as the site working. This is where you use the archive-urls.txt file from Step 1.

Crawl your rebuilt site and compare it to that list. Any URL from the old site that now shows a 404 either failed to import or needs a redirect. Every one of those is a real link from somewhere else arriving at an error page.

Then go through this list:

• Create a new sitemap and submit it in Google Search Console
• Use the URL Inspection tool on a few important pages to confirm Google can read them
• Check the publish dates on your oldest and newest posts
• Check the menu, including drop-downs
• Check links inside your posts. Old links pointing at http:// or a www version need updating
• Remove the 503 holding page so the site returns 200 again
• Check that category pages and page 2, 3, 4 of your blog all load

Getting your rankings back takes weeks, not days. Google has to visit again and find real pages where there used to be errors. Submitting the sitemap speeds up the first visit. Nothing speeds up the rest.

Step 6: Make sure this never happens again

Every recovery job starts with a backup someone assumed was running. Fix that this week, while it still feels urgent.

• Store backups somewhere other than your server. A backup on the same server disappears with the server
• Automate it. Do not rely on remembering
• Test a restore once. An untested backup is a hope, not a backup
• Write down where the backups are and who can access them

That last point matters more than it sounds. Many sites are lost because the person who set up the backups left the company and nobody else knew where they were.

What to expect

For a site with a few hundred posts and good archive coverage: about half a day to check and set up, half a day to import and fix, and a few days to clean up images and missing pages. Then a few weeks of waiting for Google.

For a site with poor coverage: you will get the important pages and lose the rest. Still worth doing, because the important pages are usually the ones with links pointing at them.

For a site with no coverage: nothing here helps. But finding that out on day one instead of day nine is worth something.

Start with the check

Run the command in Step 1 against your domain. It takes five minutes and costs nothing. It answers the only question that matters before you plan anything else.

If your pages are in the archive, this is a normal job with clear steps, not an emergency.

WP Wayback Pro is $59. One domain and its subdomains, forever. One payment, lifetime updates. Get it here.

If you would rather someone else did all of this, my care plans cover recovery work and the monitoring that stops it happening twice.