A common request in our studio: a small business has a WordPress site that nobody has updated in years. The developer is gone, the theme is from 2017, half the plugins are no longer maintained, and the host is about to switch off the PHP version it runs on. The site still brings calls from Google, and the owner is afraid that any change will lose them.

Rankings drop after a move for a short list of reasons: addresses change without redirects, pages that brought visitors disappear, a staging noindex ships to production, or the site was already compromised and the move carries the infection over. This checklist covers each of them. We use it on every website rescue and migration we take on.

1. Take a full copy before anything else

Copy the files, the database, the DNS zone and the list of accounts (registrar, host, email, analytics, Search Console) before you touch the live site.

# on the old host, if you have SSH and wp-cli wp db export backup-$(date +%F).sql tar -czf files-$(date +%F).tar.gz --exclude='wp-content/cache' . # DNS: save the current zone, including MX and TXT records dig +noall +answer example.com ANY > dns-$(date +%F).txt

Without SSH, most hosting panels have a backup button, and a plugin such as UpdraftPlus can export to your own storage. Write down where every account lives and who holds the password. On abandoned sites the hosting account is often in the former developer's name, and recovering it takes days, so start early.

2. Check whether the site is already hacked

Old WordPress installs are a common target. Before planning the move, look for signs of a compromise:

  • site:example.com in Google shows pages you never wrote (pharmacy, casino, Japanese keyword spam);
  • PHP files inside wp-content/uploads/;
  • admin users nobody recognises;
  • redirects that fire only for visitors coming from Google or only on phones. 
find wp-content/uploads -name '*.php' wp user list --role=administrator grep -rl --include='*.php' -e 'base64_decode' -e 'gzinflate' wp-content/ | head

If you find any of this, clean the site and find the way in before you migrate, otherwise the backdoor moves with the content. Our notes on hacked website repair describe the order: contain, copy the evidence, clean against vendor originals, close the entry point, rotate keys, then ask Google for a review if there is a warning.

3. Build the list of addresses to protect

Collect every URL that has search history or inbound links. Use four sources, because each one misses something:

  • the XML sitemap (often outdated on abandoned sites);
  • a crawl of the live site;
  • Search Console, Performance report, Pages tab, the last 16 months;
  • server logs, if the host keeps them.

Pay attention to the WordPress-specific addresses that a new build usually drops: /?p=123 short links, /category/ and /tag/ archives, /author/ pages, attachment pages, /feed/, paginated archives (/page/2/), and direct image URLs under /wp-content/uploads/ that other sites embed.

4. Write the redirect map

One row per old address: old URL, new URL, status code. Every old page that brought visitors or has links goes to its closest new page with a 301. Avoid sending everything to the home page; Google treats mass redirects to the home page as soft 404s.

Decide the trailing slash and the www question once and apply it everywhere. A mismatch between the redirect rules and the canonical tags creates chains and loops. On one recent rescue, the diagnosis found a redirect loop that turned 45% of requests into 301 responses before the site was even moved.

5. Test the map with a script 

#!/usr/bin/env bash # redirects.csv: old_url,expected_url while IFS=, read -r old expected; do final=$(curl -s -o /dev/null -L -w '%{url_effective} %{http_code} %{num_redirects}' "$old") read -r url code hops <<< "$final" if [[ "$url" != "$expected" || "$code" != "200" || "$hops" -gt 1 ]]; then echo "FAIL $old -> $url ($code, $hops hops), expected $expected" fi done < redirects.csv

Run it against staging with the production hostnames mapped in /etc/hosts, and again right after launch. Every line it prints is a page that will lose its rankings.

6. Launch-day checks

  • Remove noindex and the staging Disallow: / from robots.txt. This is the most common way a migration wipes a site from Google, and it is easy to check with curl -s https://example.com/robots.txt and a look at the page <head>.
  • Canonical tags point at the new production URLs.
  • hreflang pairs still match if the site has English and French.
  • Forms, phone links and analytics events work the way a customer uses them. Send a real test request.
  • Submit the new sitemap in Search Console and keep the old one for a few weeks so Google recrawls the redirects.

7. Watch the first weeks

Check Search Console coverage and 404s daily for the first week and again after three or four weeks. A short dip while Google recrawls is normal. A page that stays gone is usually a missing redirect, and the fix is one line in the map.

Repair or rebuild?

Some abandoned sites come back with updates and a cleanup. Others cost less to rebuild on a current stack than to keep patching. Make the choice with both options and their scope written down, after the copy and the diagnosis. If you are in Canada and want us to do it, the website rescue and migration page has a short quiz that asks for the address of your site.