How to Redirect After a Domain Name Change (Complete 301 Guide)

To execute a change domain name redirect without losing SEO equity, implement permanent (301) server-side redirects from every URL on the old domain to its exact 1:1 counterpart on the new domain. Configure them at the server level — .htaccess for Apache, server blocks for Nginx — never through CMS plugins or JavaScript. Submit the move through Google Search Console’s Change of Address tool, update your XML sitemap, and keep the redirects live for at least twelve to twenty-four months. Skip any of those steps and rankings will bleed.

Key Takeaways

• Domain migration redirects should follow four phases: Audit → Configure → Validate → Maintain. A 1:1 server-side 301 redirect from each old URL to its exact new counterpart is the foundation of a successful migration; the remaining phases verify and preserve that setup.
• The fatal failure modes are predictable: missed URLs, redirect chains, plugin-based rules, expired SSL on the old domain, and letting the source domain registration lapse.
• Expect three to six months of ranking volatility: recovery timeline of three to six months for full re-indexing, with caveats for site size and crawl frequency.

Why a Domain Name Change Can Destroy Your Search Equity (And How 301 Redirects Save It)

Domain changes are the highest-stakes event in domain migration SEO. They force search engines to make a binary decision: is this the same site, or a new one with no history? That decision is driven by how clearly your migration signals continuity — most critically through correct 301 redirects.

The Real Cost of a Botched Migration

When a 301 is missing, Googlebot crawls the old URL, hits a 404 — or worse, a parked domain — and over successive crawls drops it from the index. The backlinks pointing at it now point at nothing. Their authority does not transfer because there is no redirect telling Google where the signal should consolidate. Link equity that took years to accumulate evaporates.

Multiply that across a few thousand URLs and the collapse looks sudden in the dashboard. In reality it’s a slow, compounding drainage. Crawl by crawl, the index updates. Position by position, rankings slip. By the time the weekly traffic report flags it, damage has been accumulating for a month — long enough that the wrong person has already been asked to explain the numbers.

To understand the strategic implications behind these effects, see what happens to your SEO when you change domains.

Understanding the 301 Status Code

A 301 is the HTTP status code for Moved Permanently. It tells browsers, crawlers, and search engines that a URL has relocated for good and all signals — including link equity — should consolidate at the new URL.

There is a persistent myth that a 301 costs you fifteen percent of your PageRank. Retire it. Google’s current site move documentation is unambiguous — 301 and other permanent redirects don’t cause a loss in PageRank. The “15%” figure is a vestige of how the original algorithm modeled damping. It does not describe how redirects work today.

The honest caveat: full transfer in theory is not the same as full transfer in practice. Redirect chains, slow response times, and intent mismatch between source and destination URLs all degrade the operational value of the transfer. The algorithm is not subtracting equity. Sloppy implementation is wasting it.

One precision: HTTP 308 is the sibling of 301 — it also signals permanent redirection but preserves the request method (POST stays POST). For domain migrations, 301 remains the standard.

How Search Engines Process Your Migration

This is the most misunderstood part of the timeline. Googlebot crawling your 301 and Google’s index consolidating the old URL into the new one are two different events, separated by days or weeks.

The crawl is fast — hours to days. Consolidation, where the new URL inherits historical ranking signals and the old URL disappears from results, is slower and asynchronous. Do not panic on day three because the old URL is still showing up; the redirect is working and the index is catching up. Three to six weeks of noisy results and ranking volatility is normal. Three to six months is the window where rankings should stabilize toward pre-migration baselines — Google’s own framing is “a few weeks for most pages” on a medium-sized site, with larger sites taking longer.

One more precision: backlink authority transfers when Google recrawls the linking site and follows that link through your redirect. Google ties signal transfer to recrawling and reassigning links from other sites, which is why the one-year retention floor exists. Consolidation speed depends on how often Googlebot crawls the sites pointing at you, not just your own domains. High-authority referring domains get crawled more frequently — which is why outreach to update those links accelerates the process.

DNS must be stable before redirects go live. Changing DNS and redirect rules simultaneously means debugging two systems against each other.

Phase 1 — Audit: Strategy Before Syntax

The most common cause of botched migrations is not bad syntax — it is bad planning.

Mapping Every URL Before You Migrate

A complete URL audit of the source domain is the most important step in the entire migration. The output is a 1:1 redirect mapping document that pairs every old URL with its exact destination on the new domain. This mapping is the spine the rest of the domain migration hangs from.

Pre-migration URL audit checklist: 

1. Pull full URL inventory.
2. Export Google Search Console performance data.
3. Pull backlink report.
4. Identify top 50 URLs by traffic. 
5. Identify top 50 URLs by backlinks.
6. Document existing redirects.
7. Capture canonical tags.
8. Capture hreflang attributes.
9. Document server access and DNS settings.
10. Confirm SSL on both domains.

The mapping table format that holds up at scale:

Priority tiers matter more than spreadsheet aesthetics. Tier 1 is the “if this breaks, leadership notices within twenty-four hours” set: flagship products, top organic landers, paid campaign destinations, pages with the densest backlink profiles. These get manually verified after launch. Tier 2 is the bulk of the indexed site. Tier 3 is the long tail that the wildcard rule catches.

On a fifty-thousand-URL site you cannot manually QA every redirect. Tiering focuses verification budget where breakage costs the most. Identify priorities by layering three signals: traffic from Google Search Console, backlink density, and page authority. URLs scoring high on two or more belong in Tier 1, and this explicitly includes paid landing pages tied to active campaigns, which can lose budget efficiency immediately if redirects fail. To keep your PPC campaigns running smoothly, use our ad domain migration checklist.

Auditing the Existing URL Structure and Backlink Profile

The audit has a second job: cleaning up the redirects you already have.

Most established sites have accumulated three to five years of one-off redirects — old product pages, retired blog categories, defunct campaigns. If those existing 301s point at URLs that are themselves about to be redirected to a new domain, you have just built a chain. Each additional hop adds latency, consumes crawl resources, and lowers the probability of clean signal transfer.

Collapse these before migration, not after. Use a crawl tool — any reputable site auditing software — to extract the URL inventory, surface every existing redirect, and flag the chains. Cross-reference against your backlink report to confirm which source-domain URLs carry the most equity. Document the basics implementation will need: server type and version, hosting access level, DNS provider, SSL status on both domains.

Choosing the Right Implementation Method

Server-side redirects via .htaccess (Apache) or server blocks (Nginx) are the only responsible choice for a change domain name redirect. Plugin-based redirects belong nowhere in this conversation. Three reasons.

• A plugin can be deactivated by anyone with admin access. A ruleset that took two weeks to build can be silently disabled by a team member auditing plugin bloat. Server config files require shell or panel access — a smaller, more controlled audience.
• Plugin redirects fire late in the request lifecycle. The web server hands the request to the application runtime, which boots the CMS, which loads plugins, which checks the redirect rules — then the redirect issues. Server-level redirects fire before the application stack is invoked at all. At scale, that added latency operationally degrades equity transfer.
• Plugin redirects rarely cover edge cases server config handles natively. HTTP-to-HTTPS, www-to-non-www, trailing slash variants, case sensitivity — these get handled inconsistently and produce the same redirect chains the audit just eliminated.

Phase 2 — Configure: Syntax, Rule Order, and Server Setup

With the audit complete and the mapping document in hand, implementation is largely mechanical — provided syntax is exact and rule order is correct.

.htaccess 301 Redirect Configuration (Apache)

For a whole-domain redirect that preserves the full path and query string:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^(www\.)?old-domain\.com$ [NC]

RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

 

RewriteEngine On activates Apache’s mod_rewrite. The RewriteCond matches both old-domain.com and www.old-domain.com; the [NC] flag makes it case-insensitive. This is the line beginners forget — without it only one hostname variant gets caught. The RewriteRule captures the full path and query string in $1 and appends it to the new domain. [R=301,L] issues a permanent redirect and stops further rule processing.

When URL structure changes between old and new, you’ll need URL-specific rules:

RewriteEngine On

Redirect 301 /products/legacy-widget https://new-domain.com/shop/widget

Redirect 301 /blog/old-category/post-slug https://new-domain.com/blog/post-slug

 

Rule order matters: specific rules must appear before the wildcard catch-all, or the wildcard matches first and the specific rules never fire.

One quiet failure mode: .htaccess files saved from Windows editors pick up UTF-8 BOM markers or CRLF line endings. Apache silently chokes — the redirect “doesn’t work” and the only diagnostic is a 500 error or a quiet ignore. Save as UTF-8 without BOM, LF line endings.

See Apache’s mod_rewrite documentation for the directive reference.

Nginx 301 Redirect Configuration

The Nginx whole-domain equivalent:

server {

    listen 80;

    listen 443 ssl;

    server_name old-domain.com www.old-domain.com;

    return 301 https://new-domain.com$request_uri;

}

 

return 301 is the canonical Nginx pattern for whole-domain redirects — faster than rewrite because Nginx does not need to parse a regex. $request_uri preserves the full path and query string. The listen 443 ssl line must be paired with valid certificate directives for the old domain — otherwise HTTPS requests throw certificate errors that look like a hacked site and mask the redirect entirely.

For URL-specific rules:

server {

    server_name old-domain.com;

    location = /products/legacy-widget {

        return 301 https://new-domain.com/shop/widget;

    }

    location / {

        return 301 https://new-domain.com$request_uri;

    }

}

 

The location = /path syntax forces an exact match. Without the =, Nginx treats it as a prefix match and may catch deeper paths unintentionally. Order works differently than in Apache: Nginx processes location blocks by specificity, not file order, so exact matches always win regardless of position. Operators coming from Apache routinely get this wrong.

See the official Nginx documentation for the return and rewrite directives.

Handling URL Structure Changes

If URL structure is identical between old and new, a single wildcard rule covers everything. If structure changes in a consistent, patterned way — every /products/ becomes /shop/ — regex-based rewrites handle the transformation. If structure changes inconsistently — different slugs, consolidated pages, deprecated sections — you need explicit URL-by-URL rules for the affected paths and a fallback wildcard for everything else.

The trap is a wildcard rule catching a URL the specific rules should have caught first. Rule order is load-bearing, and the Tier 1 verification from the audit exists precisely for the URLs you cannot afford to let slip through.

DNS Records and the Launch Sequence

Most migrations that go sideways do so because the launch sequence got reordered.

1. Provision the new server. SSL installed, stack running, site accessible by IP or staging hostname. The new domain must be ready to serve traffic before any redirect rule is written.
2. Deploy the site to the new domain. Full content parity. All internal links pointing to new-domain URLs natively, not through redirects.
3. Verify in staging. Crawl end-to-end. Confirm no broken internal links, no orphan pages, no residual references to the old domain in the source.
4. Deploy redirect rules on the old domain. Both wildcard and URL-specific. SSL on the old domain must still be valid — expired certificates throw browser warnings that look like a hacked site.
5. Test redirects against the live old domain. Use a status code checker on a sample of Tier 1, Tier 2, and Tier 3 URLs. Confirm 301 status, single hop, correct destination.
6. Update DNS to point the old domain to the new server, or leave records in place if the old server still hosts the redirects. Propagation runs hours to forty-eight hours globally.
7. Monitor crawl errors in Google Search Console for both properties through the first thirty days. Submit the Change of Address tool. Watch for 404 spikes or sudden drops in impressions.

The most common place this breaks is step five. Writing the rules and trusting them. Rules that look correct in a configuration file fail in production for reasons invisible from the file view — a module not enabled, conflicting prior rules, SSL handshake issues, hostname mismatch. Step five is cheap insurance.

Phase 3 — Validate: Testing and Monitoring

A redirect rule that looks correct in the file is not the same as a rule that works in production. This phase catches errors that would otherwise quietly erode rankings for weeks before anyone notices.

Pre-Launch Testing

Test in staging before pointing DNS. Use an HTTP status code checker to confirm every source URL returns a 301 to the correct destination. Crawl the source domain to surface chains, loops, or URLs the rules missed. Validate HTTPS, trailing slash variations, and parameter-based URLs.

One footnote: browsers cache 301s aggressively, sometimes for weeks — MDN classifies 301 responses as heuristically cacheable when no explicit Cache-Control is sent, which is what makes the behavior so persistent. If a rule was deployed incorrectly and a developer’s browser cached the wrong destination, fixing the server rule won’t fix that developer’s experience until the cache expires. Test in an incognito window, or use curl -I against the old URL — curl bypasses browser caching entirely. If a redirect “works for some people and not others,” cached 301s are the first thing to rule out.

Using the Change of Address Tool

The Change of Address tool in Google Search Console is the only site-wide signal Google provides for a change domain name redirect at scale. Your 301s are URL-level signals; the tool is the domain-level one. Both are needed.

The procedure:

1. Verify both old and new domains as separate Domain-level properties in Google Search Console — no path segments; the tool works only at the domain level and runs pre-checks against the old property before submission. Verify both before launch.
2. Open the Change of Address tool from the old property: Settings → Change of Address.
3. Select the new property from the dropdown of verified properties.
4. Run the pre-move validation checks. Google will test that 301s are live from a sample of old URLs to the new domain. Failed critical checks block submission until the underlying issue is fixed.
5. Submit. Google posts a notification in both properties confirming the move is in progress. The notification persists for one hundred and eighty days.
6. Monitor both properties through the transition — redirect errors on the old, impressions and indexing status on the new.

One warning for multi-stage migrations: do not chain Change of Address submissions. If you migrate from A to B, wait for traffic to stabilize on B before submitting B to C. A second move cannot be submitted immediately after the first — consolidation gets unpredictable across stacked transitions.

Update your XML sitemap to reflect the new domain’s URL structure and submit it to Google Search Console and Bing Webmaster Tools immediately after launch. Audit canonical tags and hreflang on the new domain to confirm they reinforce — not contradict — the redirect signals.

Monitoring Recovery

The first ninety days are when implementation quality reveals itself. Track organic traffic against pre-migration baseline, crawl errors in both properties, indexing status of new-domain URLs, and rankings for top organic terms.

• Week one. Expect noise. Both domains may appear in results. Impressions can fluctuate thirty percent either way. The failure signal is a sustained zero — impressions dropping to near nothing on the new property means redirects are not being followed.
• Month one. Old-domain URLs appearing less frequently. New-domain impressions climbing. Rankings unstable. Total organic traffic within seventy to ninety percent of baseline if implementation is clean.
• Month three. Most consolidation complete. Traffic approaching baseline. Persistent gaps below eighty percent indicate either implementation issues — missing redirects, chains, intent mismatch — or content and structural changes on the new domain not present before.
• Month six. Recovery effectively complete. Anything still significantly below baseline at this point is unlikely to recover without active intervention. It is a problem on the new site, not a residual migration effect.

These are expectations, not guarantees. A blog with two hundred URLs and clean redirects can fully consolidate in weeks; an e-commerce site with eighty thousand URLs may need the full six months. Set Search Console alerts for sudden visibility drops or 404 spikes — that is how you catch a broken rule on week two instead of month two.

Phase 4 — Maintain: Troubleshooting and Long-Term Best Practices

Even a well-executed migration produces surprises. This phase is the troubleshooting reference for the months after launch.

Common Redirect Failures: Chains, Loops, and Cache Errors

Error	Symptom	Fix
Redirect chain	Old URL → intermediate → final; Search Console flags “Page with redirect”; visible latency.	Audit existing redirects; rewrite rules to point directly from old to final destination; collapse intermediates.
Redirect loop	Browser returns “too many redirects”; Googlebot reports the URL unreachable.	Inspect rule order; check for circular rules; confirm HTTPS rules aren’t oscillating.
Unmapped URL (404)	Old URL returns 404 instead of 301; backlinks lose their authority transfer.	Add the missing URL to the mapping; deploy a specific rule; verify it fires before any catch-all.
Mixed content error	Site loads but flags insecure resources; some redirects fail under HTTPS.	Audit internal links for http:// references; force HTTPS in server config; reissue SSL if needed.
www / non-www conflict	One variant redirects correctly, the other does not.	Ensure server config matches both domain.com and www.domain.com; verify DNS covers both.
Trailing slash conflict	/page and /page/ resolve differently; some redirect, some 404.	Normalize trailing slashes; pick one canonical form and force the other to redirect to it.
Browser cache shows wrong destination	Developer sees wrong destination after a rule fix.	Test in incognito or with curl -I; advise stakeholders to clear cache.

The most damaging of these is the redirect chain, because it is the most likely to go undetected. The site appears to work. URLs eventually resolve. But every hop adds latency and lowers the probability that any crawl cycle completes the link equity transfer. Audit for chains in month one and again in month three.

How Long to Keep 301s Active

Google’s official guidance is a minimum of one year, and the one-year clock starts when Googlebot first crawls the redirect, not when the rule is deployed. On a large or sparsely-crawled site, that can be weeks of difference. Twelve months from launch is the floor; twenty-four months is the responsible practical baseline.

For high-authority backlinks, keep redirects indefinitely. Once removed, any new signals pointing at the old URL no longer transfer. The backlink an industry publication adds in 2028 pointing at your old domain does nothing for you if the redirect was retired in 2027. Link equity preservation is permanent only if the redirect is.

A separate warning: do not let the old domain registration lapse. If it expires and gets picked up by a third party — or a squatter — every backlink pointing at the old domain now serves an unrelated site. Many enterprise migrations renew the source domain five-plus years past migration as standard practice. The registration fee is trivial against the alternative.

As the new domain’s URL structure evolves, manage redirects with the same discipline used during initial migration. Every URL change on the new domain that affects a previously-redirected path can create a new chain. Treat the mapping document as a live operational artifact.

Communicating the Change Across Your Ecosystem

Internal links on the new domain that still point at the old domain force traffic — and Googlebot — through the redirect when they could resolve natively. Auditing and replacing them is a one-time effort that removes a category of redirect-chain risk forever.

The same logic applies to owned digital properties: social profiles, email signatures, ad campaigns, directory listings, partner co-marketing pages. Update in priority order; highest-traffic owned properties first.

For high-authority external backlinks, direct outreach is worth the time. Identify the top fifty referring domains by authority, request the link be updated to the new destination, follow up once. A meaningful fraction will update — each one removes another redirect from the critical crawl path.

Notify your hosting provider and CDN of the change. CDN caches can mask redirect errors by serving cached responses from the old domain after rules have changed. Coordinating cache invalidation through launch prevents that “works for me but not for the user” problem entirely.

When the Stakes Are Too High to Migrate Alone

The procedure reduces to four phases: audit every URL and build a tiered mapping document; configure server-side 301 redirects with exact syntax and correct rule order; validate in staging and again in production; maintain the redirects for twelve to twenty-four months and the source domain registration indefinitely. A clean 1:1 server-side 301 mapping is the foundation a successful change domain name redirect rests on. Get it right and the rest is process. Get it wrong and no amount of recovery work fully closes the gap.

For a small site with a clean URL structure and a team comfortable in server configuration files, executing this guide in-house is realistic. For a high-traffic site, a complex URL structure, or a business where organic search is a primary revenue channel, the cost of one missed step exceeds the cost of having the migration audited or executed by specialists.

A domain migration only happens a handful of times in the life of a brand. The discipline of executing it well — the audit before the syntax, the validation before the launch, the maintenance long after anyone is watching — is what separates rankings that survive the move from rankings that quietly drain. If the migration ahead of you carries that kind of risk, contact our team for full-service domain migration support.