Website Verification Checklist After Migration

After migrating a site to new hosting, it's crucial to systematically check all functionality before reporting a successful migration. A missed issue can result in lost customers, transactions, or search engine rankings.

1. Basic Availability

># Check the HTTP/HTTPS response
curl -I https://example.com
# Expected response: HTTP/2 200

# Check the HTTP → HTTPS redirect
curl -I http://example.com
# Expected response: 301 Moved Permanently → https://example.com

# Check www → non-www (or the reverse)
curl -I https://www.example.com
# Should redirect to the primary domain

2. SSL Certificate

># Expiration date and trust chain
openssl s_client -connect example.com:443 -servername example.com   < /dev/null 2>&1 | grep -E "subject|issuer|notAfter"

# Online: https://www.ssllabs.com/ssltest/
# Expected grade: A or A+

3. Complete Functional Checklist

4. SEO Check

># Robots.txt is accessible
curl https://example.com/robots.txt

# Sitemap.xml is accessible and up to date
curl https://example.com/sitemap.xml | head -20

# Canonical tags are correct
curl -s https://example.com | grep canonical

# Title and description meta tags
curl -s https://example.com | grep -E "<title>|meta name="description""

5. Load Speed

># Server response time
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}
Total: %{time_total}
"   https://example.com

# Online tools:
# https://pagespeed.web.dev/
# https://gtmetrix.com/

6. Setting Up Monitoring

># Free uptime monitoring
# UptimeRobot (uptimerobot.com) — checks every 5 minutes

# Or a simple monitoring script
cat > /usr/local/bin/check-site.sh <<'SCRIPT'
#!/bin/bash
STATUS=$(curl -o /dev/null -s -w "%{http_code}" https://example.com)
if [ "$STATUS" != "200" ]; then
  echo "ALERT: Site returned $STATUS" | mail -s "Site Down!" admin@example.com
fi
SCRIPT
chmod +x /usr/local/bin/check-site.sh
echo "*/5 * * * * /usr/local/bin/check-site.sh" | crontab -

7. Rollback Plan

># Quick DNS rollback (if something went wrong)
# In the DNS panel: point the A record back to the old server's IP
# Verify with dig
dig @8.8.8.8 example.com A +short
# After verification — calmly troubleshoot the issue

Frequently asked questions

How long should the old hosting stay active after a migration?

The old hosting is worth keeping online for a while after the move — it lets you quickly roll DNS back if a critical problem turns up before the new server has been fully verified. Shutting down the old setup too early is risky: without it, an emergency data restore from backups takes far longer than simply pointing DNS back.

What's the first thing to do if a critical problem turns up right after migration?

The first step is pointing the DNS record back to the old server's IP, rather than fixing the problem on the new host while real visitors are hitting it. This quickly gives users a working site again while the old setup stays active, buying time to calmly find the cause without the pressure of a site that's down for everyone.

Why check the SSL certificate separately instead of just seeing whether the page loads?

A page can load even with a broken certificate — some browsers temporarily cache an old connection or simply ignore the warning. Checking the trust chain, expiration, and domain match on its own surfaces hidden problems that aren't always obvious right away but will show up later for some visitors using different browsers or settings.

Does uptime monitoring replace the one-time check done right after migration?

No, these are different jobs. Monitoring watches availability continuously and alerts you to a future outage, but it doesn't check forms, mail, the cart, or SEO parameters at the moment of the move itself. A full functional checklist right after migration is still needed regardless of whether monitoring is set up — the two provide different layers of protection.