WordPress Domain Migration Without Losing SEO: 301s, Canonicals, Sitemaps, and Zero Drama

What you’re actually changing (and why SEO gets cranky)

A domain migration is not “update DNS and click Save.” It is a coordinated identity swap for every URL your site has ever published. Search engines don’t rank your WordPress install. They rank your URLs and their signals: links, content, performance, structured data, and the implied promise that this URL consistently serves this thing.

When you move domains, you’re asking Google and friends to transfer trust from old URLs to new ones. That transfer happens via a chain of evidence:

• HTTP redirects (typically 301) that map old URLs to new equivalents.
• Canonical tags that say “this page’s preferred URL is here.”
• Sitemaps that list the new URLs and help discovery.
• Internal links updated to stop self-sabotaging with old-domain references.
• Consistent response behavior (status codes, cacheability, content) that doesn’t look like a bait-and-switch.

Do those well and the move is mostly a temporary wobble. Do them poorly and you create duplicate content, crawl traps, redirect loops, and long-lived indexing confusion—usually while your marketing team refreshes dashboards like it’s a cardiac monitor.

Facts and context that explain the weird parts

Some quick, concrete history and mechanics. These aren’t trivia; they explain why certain “clever shortcuts” are a bad career choice.

1. 301 vs 302 used to be interpreted more literally than today. For years, a 302 could stall signal transfer; modern engines are smarter, but 301 is still the default for permanent moves.
2. Google introduced the rel=canonical concept in 2009. It was built to reduce duplicate indexing when the same content exists at multiple URLs—exactly what you create during a migration.
3. XML sitemaps became mainstream in the mid-2000s. They don’t “boost ranking,” but they reduce discovery time and help you see coverage errors faster.
4. WordPress has supported “Site Address (URL)” vs “WordPress Address (URL)” forever. Misunderstanding that split causes half the self-inflicted outages in domain moves.
5. Browsers started enforcing stricter mixed-content rules over the 2010s. An HTTPS new domain with HTTP embedded assets can silently break rendering and tracking.
6. HTTP/2 (standardized in 2015) changed the performance cost model. Redirect chains are still expensive, but less so than the old “one connection per asset” era—still not free.
7. CDNs popularized aggressive caching of redirects. A wrong 301 can get cached at the edge and outlive your hotfix, which is exciting in the way a pager is exciting.
8. Search engines treat long redirect chains as a quality and efficiency problem. They may stop following after too many hops, and crawl budget is finite.

One paraphrased idea worth keeping in your head, because it applies directly here: paraphrased idea: “Hope is not a strategy; measure, automate, and verify.” — Gene Kim (paraphrased idea)

Non-negotiables: what must be true when you cut over

Before you touch DNS TTLs or WordPress settings, get these invariants straight. They’re not “nice to have.” They’re the boundary between “temporary dip” and “why are we deindexed.”

1) Every old URL returns a single-hop 301 to its new equivalent

Not “homepage for everything,” not a 302 “for now,” not a chain like old → http new → https new → www new. One hop. Keep it boring.

2) New pages self-canonicalize to the new domain

When a crawler hits the new domain, the canonical must point to the new domain. If canonicals still reference the old domain, you’re telling Google to prefer the old URLs… while you’re also redirecting those URLs. That’s a conflict, and conflicts don’t rank.

3) Internal links stop pointing at the old domain

Redirects are for outsiders. Your own site should not need them. Internal old-domain links inflate crawl waste and hide content issues.

4) Sitemaps and robots.txt reflect the new truth

Publish sitemaps listing the new URLs only. robots.txt should not accidentally disallow important paths because someone copied a staging rule.

5) Tracking and critical integrations survive

Analytics, payment callbacks, OAuth redirect URIs, webhooks, CSP headers, email templates, and marketing pixels are all domain-sensitive. List them up front.

Joke #1: A domain migration without a redirect map is like changing your office address and then acting surprised when your mail goes to “Unknown Resident.”

Fast diagnosis playbook (check these in order)

When traffic or indexing looks wrong, don’t flail. Run a short, repeatable triage that finds the bottleneck fast.

First: are redirects correct and single-hop?

• Pick 20 high-traffic URLs from analytics and test status codes, Location headers, and hop count.
• Confirm HTTP→HTTPS and non-www→www decisions don’t create extra hops.
• Confirm old domain serves nothing but redirects (except maybe ACME challenges).

Second: are canonicals coherent?

• On the new domain, view source and confirm canonical points to the new domain.
• Check that paginated archives, category pages, and products use consistent canonical rules.
• Confirm no plugin is rewriting canonicals to the old host.

Third: can crawlers discover and fetch the new URLs efficiently?

• Verify sitemaps load, are not blocked, and list the correct host.
• Check robots.txt: no accidental disallow, sitemap directive points to the new domain.
• Confirm server responses are stable: no 5xx spikes, no WAF blocks for Googlebot.

Fourth: are you accidentally duplicating the site on multiple hosts?

• Ensure only one “preferred” host is indexable (www vs apex). Other hosts should 301.
• Ensure old domain isn’t serving 200 OK pages through a bypass (origin IP, forgotten vhost).

Fifth: are caches lying to you?

• Purge CDN caches for redirects and HTML.
• Check whether a “bad 301” got cached with long TTLs.
• Confirm WordPress page cache isn’t serving old canonical tags.

Checklists / step-by-step plan (pre-flight to post-flight)

Phase 0: Decide what “same URL” means

If you are changing only the domain (oldsite.com → newsite.com) but keeping paths identical, life is easier. If you’re also changing permalink structure, merging categories, or “cleaning up content,” stop. Split it into two projects. Domain migration is already enough risk.

Phase 1: Inventory and mapping

• Export a list of indexed URLs (Search Console), top landing pages (analytics), and sitemap URLs (old).
• Create a redirect map: old URL → new URL, including edge cases (trailing slash, uppercase, legacy assets).
• Decide preferred host: apex vs www. Pick one and commit.

Phase 2: Build the new site in parallel

• Bring up the new domain in staging with HTTPS.
• Set WordPress Home/Site URLs to the new domain in a controlled way.
• Update internal links, media URLs if needed, and canonical behavior.
• Generate new sitemaps and verify they list only new-host URLs.

Phase 3: Pre-cutover verification

• Run a crawl of the staging/new domain and check canonical, status code, and internal link host distribution.
• Test redirect rules against a sample list of old URLs before the world sees them.
• Set DNS TTL low enough in advance (not five minutes before cutover).

Phase 4: Cutover

• Enable redirects on the old domain (server-level preferred).
• Switch DNS or load balancer routing for the new domain.
• Verify certificates (both old and new if old is serving HTTPS redirects).
• Watch logs and error rates like you mean it.

Phase 5: Post-cutover cleanup (first 72 hours)

• Submit new sitemaps, request indexing of key pages.
• Monitor 404s and redirect loops; fix mapping gaps.
• Update third-party integrations and allowed domains.
• Keep old domain redirects live long-term (think a year+; longer is fine).

Practical tasks with commands, outputs, and decisions (12+)

These are production-grade checks. Each one has: command → typical output → what it means → what you decide next. Run them from a shell with network access to your site and, when needed, your servers.

Task 1: Verify a single URL does a clean one-hop 301

cr0x@server:~$ curl -I https://old.example.com/products/widget
HTTP/2 301
date: Sat, 27 Dec 2025 10:11:02 GMT
location: https://new.example.com/products/widget
cache-control: max-age=3600

Output meaning: HTTP 301 is correct; Location points to the exact new URL; no intermediate hop shown here.

Decision: If Location points to homepage or wrong path, your redirect map is incomplete or too generic. Fix rules before cutover or before indexing damage spreads.

Task 2: Measure redirect hop count (chains kill efficiency)

cr0x@server:~$ curl -s -o /dev/null -w "%{url_effective} %{num_redirects} %{http_code}\n" -L https://old.example.com/products/widget
https://new.example.com/products/widget 1 200

Output meaning: One redirect then a 200 on the final URL.

Decision: If num_redirects > 1, reduce hops by collapsing rules (e.g., combine http→https and host normalization into one redirect where possible).

Task 3: Confirm the old domain never serves 200 content

cr0x@server:~$ curl -I https://old.example.com/
HTTP/2 301
location: https://new.example.com/

Output meaning: Old domain is strictly a redirector.

Decision: If you see HTTP 200 with HTML, you are running two indexable copies. That’s duplicate content and canonical confusion. Make old domain redirect-only.

Task 4: Spot-check canonical tags on the new domain

cr0x@server:~$ curl -s https://new.example.com/products/widget | grep -i -m1 canonical

Output meaning: Canonical points to the new host and the correct path.

Decision: If it points to old.example.com, you are telling crawlers to prefer the old domain. Fix WordPress settings, SEO plugin config, and any hard-coded theme behavior.

Task 5: Detect mixed content (common after HTTPS migration)

cr0x@server:~$ curl -s https://new.example.com/ | grep -Eo 'src="http://[^"]+' | head
src="http://old.example.com/wp-content/uploads/2023/hero.jpg

Output meaning: The HTML includes HTTP asset URLs (and on the old domain).

Decision: Replace in database and/or enforce content rewriting. Mixed content can break page rendering and quietly degrade SEO signals.

Task 6: Confirm sitemap lists the new host

cr0x@server:~$ curl -s https://new.example.com/sitemap_index.xml | head -n 12



https://new.example.com/post-sitemap.xml

Output meaning: Sitemap index exists and references new-domain sitemaps.

Decision: If loc entries point to old domain or http, fix your sitemap generator settings and purge caches.

Task 7: Validate robots.txt isn’t blocking the new site

cr0x@server:~$ curl -s https://new.example.com/robots.txt
User-agent: *
Disallow:
Sitemap: https://new.example.com/sitemap_index.xml

Output meaning: No global disallow; sitemap points correctly.

Decision: If you see Disallow: / or staging rules, fix immediately. A single bad robots.txt can make your beautiful redirects irrelevant.

Task 8: Ensure WordPress Home/Site URLs are correct via WP-CLI

cr0x@server:~$ wp option get home
https://new.example.com
cr0x@server:~$ wp option get siteurl
https://new.example.com

Output meaning: WordPress thinks it lives at the new domain for both values.

Decision: If these are old domain (or mismatch), fix with WP-CLI and flush caches. Mismatched home/siteurl creates redirect loops and broken admin sessions.

Task 9: Search for old-domain strings in the database (dry run)

cr0x@server:~$ wp search-replace 'old.example.com' 'new.example.com' --dry-run --all-tables
+-----------------------+--------------+--------------+
| Table                 | Column       | Replacements |
+-----------------------+--------------+--------------+
| wp_posts              | post_content | 812          |
| wp_postmeta           | meta_value   | 144          |
| wp_options            | option_value | 19           |
+-----------------------+--------------+--------------+
Success: 975 replacements to be made.

Output meaning: Old-domain references are embedded in content/meta/options.

Decision: Plan the real run in a maintenance window, with a backup first. If replacements are massive, consider whether you have serialized data and rely on WP-CLI’s safe handling (it does serialization-aware replacement).

Task 10: Execute the replacement (after backup)

cr0x@server:~$ wp search-replace 'old.example.com' 'new.example.com' --all-tables --precise
Success: Made 975 replacements.

Output meaning: Database references updated.

Decision: Immediately purge page cache and object cache. Then re-check canonical tags and internal link hosts with a quick crawl or grep sampling.

Task 11: Find top 404s in NGINX access logs after cutover

cr0x@server:~$ sudo awk '$9==404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
48 /wp-content/uploads/2019/legacy-logo.png
31 /category/old-campaign/
19 /products/widget-pro/

Output meaning: These paths are being requested and returning 404.

Decision: Add targeted redirects or restore missing assets. For content pages, map to best equivalents. For assets, either serve them or redirect to their new location; avoid redirecting every missing file to homepage.

Task 12: Confirm TLS cert coverage for both domains

cr0x@server:~$ echo | openssl s_client -servername old.example.com -connect old.example.com:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = old.example.com
issuer=CN = R3, O = Let's Encrypt
notBefore=Dec 10 00:00:00 2025 GMT
notAfter=Mar  9 23:59:59 2026 GMT

Output meaning: Old domain has a valid cert, which matters if it redirects over HTTPS.

Decision: If old domain cert is invalid/expired, browsers and crawlers may not follow redirects reliably. Renew it and automate renewal; don’t let the old domain rot.

Task 13: Validate host normalization (www vs apex) behaves as planned

cr0x@server:~$ curl -I https://new.example.com/ | sed -n '1,5p'
HTTP/2 301
location: https://www.new.example.com/

Output meaning: new.example.com redirects to the chosen canonical host (www in this example).

Decision: Ensure every non-preferred host 301s to the preferred. Then ensure WordPress itself is configured to generate the preferred host in links and canonicals.

Task 14: Identify redirect loops quickly

cr0x@server:~$ curl -I -L --max-redirs 5 https://old.example.com/wp-admin/ 2>&1 | tail -n 6
curl: (47) Maximum (5) redirects followed

Output meaning: A loop exists—often caused by conflicting redirects between WordPress, the web server, and a CDN.

Decision: Inspect where the redirect changes host/proto/path. Then choose one layer to own normalization (prefer the edge/web server), and configure WordPress to match.

Redirect strategy: 301s that don’t melt down

Redirects are the migration’s spine. If they’re wrong, everything else becomes a Band-Aid on a broken femur.

Principles that hold up under load

• Use server-level redirects, not a WordPress plugin. You want redirects to work even if PHP is down, and you want them fast.
• Prefer exact mappings for top pages. For the long tail, a general rule is fine (same path on new domain), but don’t guess on high-value pages.
• Avoid redirect chains. One hop is the goal. Two is tolerable in emergencies. Three is how you end up debugging “why doesn’t Google see it” for months.
• Do not redirect everything to the homepage. That’s a soft-404 pattern and it throws away relevance signals.
• Keep redirects live for a long time. External links and old bookmarks don’t expire because your roadmap says they should.

Nginx example: old domain to new domain, preserve URI

cr0x@server:~$ sudo nginx -T | sed -n '1,40p'
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# ...snip...
server {
    listen 443 ssl http2;
    server_name old.example.com;

    return 301 https://www.new.example.com$request_uri;
}

Output meaning: Nginx config test succeeded; server block returns a single 301 preserving path and query string.

Decision: If you also need host normalization on the new domain, do it carefully so old→new is still one hop. Often that means redirecting old directly to the preferred new host.

Apache example: old to new in a vhost or .htaccess

Apache works fine; just avoid stacking rules in a way that creates loops or extra hops. If you can place redirects in the vhost config rather than .htaccess, do that for performance and clarity.

Query strings: keep them unless you have a reason not to

Campaign parameters and tracking query strings should carry over. Stripping them might simplify logs, but you’ll be blind during the weeks you most need attribution.

Joke #2: A cached 301 at the CDN edge is like glitter: once it’s wrong, it’s wrong everywhere and forever.

Canonicals: the silent assassin of your rankings

If redirects are the spine, canonicals are the nervous system. They don’t always show up in “basic checks,” but they control which URL gets credit.

What canonical tags should look like during and after migration

• On the new domain: canonical points to the new URL (self-referential canonical is normal).
• On the old domain: ideally you never serve 200 pages, only redirects. If you must serve temporary content, canonicals should still point to the new domain—carefully and consistently.
• Choose one host variant: www or apex. Canonical must match it exactly.
• HTTPS everywhere: canonical must be https if that’s your canonical scheme.

Where canonicals go wrong in WordPress

• SEO plugin config pinned to the old site URL. Some plugins store absolute URLs in settings or caches.
• Hard-coded canonical in theme templates. Someone “optimized SEO” in 2018 and left a landmine.
• Page cache serving old HTML. You fixed the database, but the cache is still shipping old canonicals.
• Multisite and domain mapping quirks. Canonical generation can depend on site IDs and mapping tables; a “simple search-replace” may be insufficient.

Canonical vs redirect: which wins?

In practice, search engines resolve signals using multiple hints. If your redirect says “go here” but your canonical says “prefer the old one,” you’ve created a debate. Crawlers love clear instructions. They’re less enthusiastic about family arguments.

Sitemaps: make Google’s job boring

Sitemaps are not magic ranking dust. They are operational tooling for indexing. In a migration, that’s exactly what you need: faster discovery, clearer reporting, fewer “unknown unknowns.”

Rules for sitemaps after a domain change

• Generate sitemaps that list only new-domain URLs.
• Expose sitemap index at a stable location (common default is fine).
• Ensure sitemaps are 200 OK, not behind auth, not blocked by WAF challenges.
• Keep old sitemaps accessible if they’re requested, but they should 301 to new sitemap locations or be replaced with new-domain references.

Image and video sitemaps

If your business relies on image search or rich results, don’t forget image sitemap entries. A domain migration can “work” for HTML while media discovery quietly tanks because the image URLs are still old hostnames or blocked by hotlink rules.

Search Console and analytics: prove it worked

This is where you turn “I think it’s fine” into evidence. You need two kinds of proof: crawler-facing correctness and user-facing behavior.

Search Console essentials

• Add and verify the new domain property (domain-level if possible).
• Submit new sitemaps.
• Use the change-of-address tool if applicable to your setup (when moving between domains under the same verified ownership).
• Monitor coverage reports: spikes in “Excluded,” “Crawled – currently not indexed,” or “Duplicate, Google chose different canonical” are actionable signals.

Analytics essentials

• Update default URL settings where needed (depends on analytics stack).
• Verify referral exclusions and cross-domain tracking, especially if you have checkout flows.
• Annotate the migration time and major fixes (redirect rule changes, sitemap resubmissions).

Log-based verification beats dashboard feelings

Dashboards tell you outcomes. Logs tell you causes. During the first week, you want both, but logs are where you’ll see bot fetch patterns, redirect loops, and 404 clusters before a report aggregates them into a vague “decline.”

Caching/CDNs and performance side effects

Domain migrations often include a CDN change, TLS termination changes, or “while we’re here, let’s add WAF.” That’s fine. It’s also how you accidentally introduce crawler blocks and caching bugs.

Redirect caching: helpful until it isn’t

A 301 is cacheable by browsers and intermediaries. That’s a feature. It’s also why you must test redirect rules before going live. If you ship a wrong 301 with a generous cache-control, you’ve distributed your mistake to every edge location and user agent that touched it.

Page cache and object cache

After changing domains, you must purge:

• Full-page cache (plugin, reverse proxy, CDN).
• Object cache (Redis/Memcached) because options and rendered fragments can be cached.
• Opcode cache if you deployed new config that affects URL generation (less common, but don’t assume).

WAF rules and bot behavior

WAFs love false positives during migrations because traffic patterns change: more bot fetches, more 404 probes, more bursts. Make sure your WAF allows legitimate crawlers and doesn’t serve JavaScript challenges to them.

Storage, backups, and rollback: treat content like data

WordPress migrations are data migrations. The domain is just the most visible piece.

Back up the database and uploads like you want to keep your job

You need a point-in-time snapshot of:

• The database (transaction-consistent if possible).
• wp-content/uploads (and any custom content directories).
• Configuration: wp-config.php, web server vhosts, CDN rules, DNS records.

Rollback plan: simple, tested, and not theoretical

A rollback for a domain migration is usually DNS + routing reversal plus disabling redirect rules. But it only works if:

• The old site can still serve the original content correctly.
• You didn’t mutate the database in a way that breaks the old domain (e.g., irreversible replacement without snapshot).
• You can re-issue valid certs quickly for both domains.

Storage edge case: hotlink protection and legacy assets

Many sites have hotlink protection keyed to referrer or host. When you move domains, that protection can block your own pages from loading images if the rules weren’t updated. If your assets are in object storage behind a CDN, validate host headers and signed URL behaviors.

Three corporate mini-stories from the migration trenches

Mini-story 1: The incident caused by a wrong assumption

The company was mid-rebrand. New domain, new logo, same WordPress. Someone said, confidently, “We’ll just set the new domain in WordPress and it will handle redirects.” It sounded plausible. WordPress does redirect some admin flows and tries to be helpful. Helpful is not the same as correct.

Cutover night went smoothly until morning traffic hit. Paid campaigns landed on the old domain and got redirected… sometimes. Other times, visitors got a 200 OK old homepage because a forgotten Apache vhost still served content on the old host when the request arrived without SNI during a TLS misconfiguration. Meanwhile, product pages on the new domain had canonicals pointing to the old domain because the SEO plugin had cached site URLs.

The result was a perfect storm of “two sites, one content set.” Crawlers saw duplicates. Users saw inconsistent behavior. Internal teams argued because each person tested a different URL and got a different reality.

The fix was boring: force old domain to redirect at the edge for all requests, renew the old cert properly, purge caches, and re-generate canonicals. Then they spent two weeks cleaning up the long tail of missing redirects discovered in logs.

The lesson: don’t assume the application layer owns the migration. Make the web server or CDN the source of truth for old→new redirects, and make the app generate consistent canonicals for the new host.

Mini-story 2: The optimization that backfired

A different org wanted the migration to be “fast for crawlers.” Their plan was to keep the old site serving 200 OK for a month while adding rel=canonical pointing to the new domain, on the theory that it would preserve user experience and “gradually transition Google.” They also used 302 redirects for some paths “just in case we need to roll back.”

It sounded cautious. It was not. They created three conflicting signals: 200 OK content on old URLs, sometimes 302 redirects, and canonicals pointing elsewhere. Crawlers responded by hedging: indexing both versions, picking their own canonicals, and delaying consolidation because nothing looked authoritative.

Then the CDN “helpfully” cached a subset of the 302s with long TTLs. Some clients kept seeing the old domain for weeks; others flipped immediately. Support tickets got weird because users were literally in different universes depending on cache state.

After chasing ghosts, they switched to consistent 301 redirects for all old URLs, made the old domain redirect-only, and removed the “soft transition” complexity. Indexing stabilized. Rankings recovered.

The lesson: migrations are not a place for signal ambiguity. If the move is permanent, use 301s, not vibes.

Mini-story 3: The boring but correct practice that saved the day

Another team did a domain migration so uneventful that nobody outside engineering noticed. Which is the best compliment you can get.

They started with a redirect map built from three sources: existing sitemaps, top landing pages, and server logs for the last 30 days. They categorized URLs into: “must map exactly,” “can map by rule,” and “intentionally retired.” Retired pages got thoughtful redirects to nearest equivalents—not the homepage—unless they truly had no replacement, in which case they returned a 410.

They tested redirects in a staging environment by replaying a list of old URLs and verifying status codes and Location headers automatically. They also checked canonical tags and sitemap hostnames with a small script and didn’t cut over until the error count was zero.

On cutover, they had DNS TTL lowered days earlier, certs already issued, and caches configured with sane TTLs for redirects. The post-cutover “war room” was mostly watching graphs remain boring and responding to a small list of 404s from obscure legacy assets.

The lesson: boring engineering practices—inventory, automation, and verification—are not bureaucracy. They are how you avoid emergency meetings with too many people.

Common mistakes: symptoms → root cause → fix

1) Rankings drop hard and stay down after two weeks

Symptoms: New pages indexed slowly; old pages linger; “Duplicate, Google chose different canonical” increases.

Root cause: Conflicting signals: redirects not consistent, canonicals still point to old domain, or multiple host variants return 200.

Fix: Make old domain redirect-only. Ensure a single preferred host on new domain. Audit canonicals site-wide and purge caches. Collapse redirect chains to one hop.

2) Everything redirects to the homepage

Symptoms: Users complain “links don’t go to the right product”; Search Console shows soft 404s; long-tail traffic disappears.

Root cause: Overly broad redirect rule without path preservation or missing mapping table.

Fix: Implement path-preserving host redirect. Add explicit redirects for moved/renamed sections. Use logs to prioritize high-volume 404s and fix iteratively.

3) Infinite redirect loops

Symptoms: Browser shows “too many redirects”; curl hits max-redirs; admin login breaks.

Root cause: Conflicting normalization between CDN, web server, and WordPress home/siteurl; mixed HTTP/HTTPS enforcement.

Fix: Pick one layer to enforce scheme and host (prefer edge/web server). Set WordPress home and siteurl to the final canonical. Ensure X-Forwarded-Proto is correct behind a proxy.

4) New site loads but images/CSS are broken

Symptoms: Missing styling, broken images, console errors; SEO performance metrics degrade.

Root cause: Mixed content (http assets), old-domain hard-coded asset URLs, or hotlink protection keyed to old domain.

Fix: Database search-replace for old hostnames; update CDN/hotlink rules; ensure HTTPS asset URLs. Purge caches.

5) Search Console shows “Submitted URL blocked by robots.txt”

Symptoms: Sitemap submitted but URLs excluded; crawl stalls.

Root cause: Staging robots.txt deployed to prod or plugin set to discourage indexing.

Fix: Fix robots.txt and WordPress “Discourage search engines” setting. Request re-crawl and resubmit sitemaps.

6) Redirects work for humans but crawlers get blocked

Symptoms: In logs, Googlebot gets 403/429; indexing slows; WAF dashboards show blocks.

Root cause: WAF/bot protection not tuned for crawler behavior; rate limits too strict; challenge pages served.

Fix: Allowlist verified crawler IPs where appropriate (carefully), reduce false positives, and ensure bots can fetch sitemaps and HTML without JS challenges.

7) Old domain still ranks instead of new domain

Symptoms: SERPs show old URLs; new URLs appear sporadically; backlinks seem “not transferring.”

Root cause: Old URLs return 200 or have canonicals to themselves; redirects are 302 or inconsistent.

Fix: Convert to consistent 301s. Eliminate old-domain 200 responses. Ensure new URLs self-canonicalize. Keep redirects stable for the long haul.

FAQ

1) How long should I keep the old domain redirects?

At least 12 months. Longer is safer. External links, bookmarks, and slow-moving crawlers will keep hitting old URLs for years.

2) Should I use a plugin for redirects in WordPress?

No for the domain-wide move. Do redirects at the web server or CDN. Use WordPress-level redirects only for a small number of editorial fixes where you need UI convenience.

3) Do I need to change permalink structure during the domain move?

Don’t. Separate projects. If you change both domain and URL paths at the same time, debugging becomes archaeology.

4) What’s the best redirect: 301 or 308?

Both are permanent. 308 preserves method strictly; 301 is universally understood and conventional for web content. Use 301 unless you have a strong reason to do otherwise.

5) Do I have to update internal links if redirects work?

Yes. Internal links pointing to the old domain waste crawl budget and hide issues. Update them so the site navigates directly to the canonical URLs.

6) What about www vs non-www?

Pick one preferred host and enforce it everywhere: redirects, canonicals, sitemaps, and WordPress settings. Inconsistency here creates duplicate URLs that compete with each other.

7) Will there be a traffic drop no matter what?

Usually there’s a short-term wobble. The goal is minimizing duration and magnitude by providing consistent signals and avoiding crawl inefficiencies (chains, duplicates, blocked resources).

8) Can I delete the old site content immediately after the move?

Delete content, yes. Delete the old domain infrastructure that serves redirects, no. Keep old domain serving fast, reliable redirects over HTTPS with valid certs.

9) How do I handle retired pages with no replacement?

If there’s no meaningful equivalent, returning 410 can be appropriate. If there is a close alternative, redirect to that. Avoid redirecting everything to homepage; it looks like a soft 404 pattern.

10) Do I need to resubmit disavow files or anything like that?

That’s case-specific and uncommon nowadays. Focus first on redirects, canonicals, and sitemap correctness—those are the levers that move outcomes reliably.

Practical next steps

If you want a domain migration that doesn’t become a recurring meeting, do three things now:

1. Build a redirect map from real data (sitemaps, analytics, logs) and test it with curl before cutover.
2. Audit canonicals and internal links on the new domain, then purge every cache layer that can serve old HTML.
3. Operationalize verification: watch logs for 404 clusters, confirm single-hop redirects, and keep the old domain’s TLS and redirects healthy for the long term.

SEO during a migration is mostly about reducing ambiguity. Give crawlers one clear story, serve it consistently, and don’t “optimize” yourself into a corner.