Keep link equity during a domain split: redirects and canonicals

What can go wrong in a domain split (in plain terms)

A domain split is when you move part of a site to a new domain while the rest stays put. The split is usually by product (moving one product line to its own domain) or by region (moving a country section to a local domain).

The risk is straightforward: the web already knows your old URLs. They have backlinks, history, and trust. If those old URLs suddenly lead to the wrong place, to multiple places, or to nowhere, you can lose ranking power even if the content still exists.

Backlinks usually lose value during a split for three reasons:

• Redirects are missing or go to a generic page (like the new homepage), so the meaning of the link gets diluted.
• Canonicals send mixed signals, telling search engines a different URL is the “real” one.
• Internal links still point to the old domain, so you keep reinforcing the old addresses and slow down discovery of the new ones.

Success looks boring, and that’s good: rankings wobble a little, then settle; organic traffic returns; and the new domain’s pages get indexed quickly without lots of “duplicate” or “alternate page” issues.

The core rule for preserving authority in a split is simple: each old URL should have one clear destination that matches intent. If an old page was a specific product feature, it should land on the matching feature page on the new domain, not a category page.

Before you move anything, do a quick sanity check. Make sure every important old URL has exactly one planned new URL, the match is easy to explain in one sentence (same topic, same purpose), and you aren’t creating situations where multiple old URLs “fight” to canonicalize to the same new URL. Also confirm the old site won’t keep linking heavily to pages that now live elsewhere, and that you have a way to spot key pages dropping out of the index after launch.

Decide the split scope before you touch redirects

Domain splits fail most often because the scope is fuzzy. Before you set up a single 301, write down exactly what is moving and what is staying. Think in terms of real pages, not ideas like “the product” or “the EU site”. If a page has backlinks today, it needs a clear destination tomorrow.

Start by listing the URLs that will move, plus the ones that must stay on the current domain (including support pages, docs, pricing, blog posts, and any high-value landing pages). This is also where you catch gray areas, like a shared FAQ that serves both parts of the business.

Then choose a split shape that matches how users search and how your content is organized:

• Folder split: best when the section already lives under one path (example.com/product/). Usually simplest.
• Subdomain split: useful when the section needs different tech or teams (product.example.com).
• New root domain: strongest separation, but highest risk if mapping is sloppy.

Before you commit, confirm the new domain is ready to be crawled and ranked. It should be on HTTPS, fast enough on mobile, and not blocked by robots rules or accidental noindex tags. Also make sure analytics and search tools are set up, so you can compare before and after.

Pick a short freeze window for content and URL changes. During the freeze, avoid renames, navigation edits, and CMS migrations. A stable baseline makes issues easier to spot.

Example: if you are moving a “/fr/” region to a new domain, decide whether every French page moves (including French help articles), or only the storefront. That one decision changes your redirect map and your internal linking rules.

Build the URL mapping that preserves meaning

Your URL mapping is the document that decides whether you keep authority during a split or quietly throw it away. Treat it like a contract: every important old URL must have one clear destination.

Start with a spreadsheet that lists all indexable URLs on the old domain, then add a “new URL” column. Aim for one-to-one matches whenever possible. If the page topic stays the same, the destination should be the closest equivalent page, not a category or the home page.

Prioritize what matters most first: URLs that already have authority and demand. Pull them to the top of the sheet using data you already have (top landing pages from analytics, pages that get clicks in Search Console, and any list of pages with strong backlinks). These are the pages where a mapping mistake hurts fastest.

Your mapping table doesn’t need to be fancy, but it should be complete. Most teams track the old URL, new URL, page type and owner, whether the page is kept/merged/retired (with a reason), and a simple QA checkbox to confirm it’s been tested.

Handle edge cases upfront. If a product is discontinued, redirect to the closest replacement (or a permanent “discontinued” page), not a generic page. If two old pages will become one, choose the best single target and plan how you will preserve the missing details on that new page.

Finally, lock down URL rules before anyone starts building. Decide how you will treat trailing slashes, uppercase, and query strings, and apply one standard everywhere. For example: force lowercase, keep or remove trailing slashes consistently, and strip tracking parameters so they do not create duplicate targets.

Redirect guardrails that protect backlink value

When you split a domain, you’re not just moving pages. You’re moving trust that other sites have already given you. If you want to preserve that value, your redirects should be boring, direct, and consistent.

The first rule is simple: use 301 redirects for permanent moves. A 301 tells search engines the move is final and helps pass ranking signals. A 302 is for temporary moves, and it often slows down how quickly value transfers.

Good redirects also respect intent. If an old URL was a pricing page, it should land on the closest pricing page on the new domain, not the homepage. Sending everything to one page often looks like a soft 404 and wastes the relevance that made the backlink valuable.

Use these guardrails:

• Redirect every indexable old URL to one best matching new URL.
• Keep it to one hop: old URL to final URL (no chains).
• Test for loops (A to B, then back to A) before you go live.
• Don’t mix signals: avoid redirecting a URL that also returns a canonical to a different page.
• Keep redirects long term, measured in months and years, not weeks.

Example: if your EU product moves to a new domain, an old blog review linking to /eu/product-x should redirect to the new /product-x (EU) page, not a generic /eu landing page.

Canonical rules for split sites

Canonicals are your “this is the main page” signals. During a split, they help search engines avoid treating very similar pages across two domains as duplicates. Used the wrong way, they can also block the new domain from ranking.

Use rel=canonical when two URLs show basically the same content (same product, same copy, same intent) and you want one preferred version indexed. Don’t use it as a substitute for a redirect. If a page has truly moved, a 301 redirect is the clearer signal.

A common trap is mixing cross-domain canonicals with redirects in a way that fights itself. If old-domain Page A 301-redirects to new-domain Page B, then Page B should not canonical back to Page A. That creates conflicting instructions.

On the new domain, add self-referencing canonicals on the pages you want indexed. This reduces duplicate risk from parameters, sorting, tracking tags, or alternate paths. It also makes audits easier because every important page points to itself as the preferred version.

Keep URL versions consistent so canonicals don’t split signals:

• HTTPS only
• One host (www or non-www)
• One trailing-slash style
• Don’t index both clean URLs and parameter versions

Example: you move /product/x to a new domain for a standalone product. The old URL 301s to the new URL. The new page has a self-canonical to its own HTTPS preferred version. Internal links and sitemaps point only to that preferred URL, not to alternates.

Internal link guardrails after the split

External backlinks get most of the attention, but internal links decide where crawlers spend their time and which pages feel “most important.” Treat internal linking like a controlled handoff, not a gradual drift.

Start with the biggest internal signal sources: navigation, footer, header utility links, and any sitewide promos. These links appear on every page, so one wrong destination can keep sending users (and bots) back to the old domain long after the move.

A practical rule: moved pages should link to the new domain version of moved content, and to the old domain version of content that stayed. Avoid “half-moved” paths where you create two competing routes to the same thing.

Focus your first pass on:

• Navigation, footer, breadcrumbs, and category paths
• Contextual links inside body copy (blog posts, help articles, comparison pages)
• Removing old-domain links that keep users looping around the moved section instead of crossing over
• Publishing separate XML sitemaps (one per domain)

Example: if you split a “/eu/” region to a new domain, make sure every EU page’s breadcrumb and header selects the new domain, while US pages keep pointing internally to US content. Don’t let a global footer keep linking to the old EU pages “because it’s easier.”

On-page and technical consistency checks

A split can look perfect in redirects, but still leak value if the new pages don’t feel like true replacements. Search engines compare intent, page layout signals, and technical hints across both domains.

Make the moved pages consistent in how they present themselves. Use one template standard for titles, H1s, and meta descriptions so the new domain doesn’t suddenly look like a different site for the same query. Keep wording natural, but keep the role of the page the same (product page stays a product page, location page stays a location page).

Meaning matters more than matching every sentence. If the old page answered “pricing and plan details” and the new page becomes a thin signup page, you’re asking Google to treat it as a different destination.

Run a tight technical check on the new domain:

• Structured data: confirm all URL fields (like "url", "@id", "logo") point to the correct domain and preferred page version.
• Canonical tags: verify each moved page self-canonicals to its new URL (unless you intentionally use a different canonical).
• Hreflang: if you use it, make sure language or region alternates reference the right domain for each market.
• Indexing controls: confirm robots meta and X-Robots-Tag aren’t accidentally set to noindex.
• Media and scripts: ensure key assets load and aren’t blocked.

Example: if you move /uk/support to a new UK domain, the new page should keep the same support intent, not switch to a sales pitch. Keep the FAQ and contact options, update structured data URLs, and make hreflang point to the UK domain for en-GB while other regions point to their correct homes.

A realistic split example (product or region)

Example 1: moving a product line to a new brand domain

A SaaS company has one main site (example.com). Over time, their “Analytics” product becomes a standalone brand, so they move it to a new domain (analyticsbrand.com). The goal is to preserve authority from reviews, partner pages, and old blog mentions that already point to example.com.

They start with a simple rule: if a page is primarily about the Analytics product, it gets a one-to-one redirect to the closest matching page on the new domain. If the page is broader (company news, hiring, non-Analytics docs), it stays.

Typical mapping decisions:

• Product pages: example.com/analytics/features -> analyticsbrand.com/features
• Pricing: example.com/analytics/pricing -> analyticsbrand.com/pricing (avoid redirecting to the homepage)
• Blog posts: keep posts about general SEO/product strategy on example.com, but redirect posts that are purely Analytics tutorials to the new domain
• Support docs: redirect only the docs that match the Analytics product; leave shared platform docs on the original domain
• Comparison pages: redirect if the comparison is for Analytics; otherwise update internal links and keep the page where it best fits

Shared resources need extra care. For images and PDFs, decide one “owner” domain. If you keep files on example.com, make sure the new site references them consistently and don’t create chains (old URL -> intermediate -> final). For shared pages like legal terms or security notes, pick one canonical version and link to it from the other site instead of publishing two competing copies.

Example 2: moving a country site to a regional domain

If you move example.com/de/ to example.de, treat each locale URL as its own mapping project. Keep language and intent aligned: German product page to German product page, not to an English fallback.

Common mistakes that waste existing backlinks

Most backlink value is lost in a split for one simple reason: the move looks unclear to search engines. The goal is to send one consistent message about what moved, where it lives now, and which version should rank.

A common failure is launching both domains without a complete URL map. Teams start redirecting “as they go,” and important pages get missed. Those missed URLs often include the ones with the best backlinks, like old product docs, comparison pages, or regional landing pages.

Another classic mistake is redirecting everything to the new homepage. It feels safe, but it breaks relevance. If a tech blog linked to a specific feature page, sending that link to a generic homepage tells Google the original page no longer exists in a meaningful way.

Watch for these patterns:

• No one-to-one URL mapping before launch
• “Catch-all” redirects to the homepage instead of the closest matching page
• 301 redirects pointing to Page B while the canonical tag on Page B points back to Page A
• Internal links still pointing to the old domain
• Changing URL structure and rewriting content at the same time as the split

Conflicting signals are especially costly. For example, if /product/widget on the old domain 301s to newdomain.com/widget, but the new page’s canonical points to the old URL (or to a different path), you’re effectively asking Google to ignore your redirect.

Monitoring checklist for the first 30-90 days

A split isn’t “done” when redirects go live. The next 30-90 days are when search engines test your changes, and small mistakes can quietly drain authority.

Save a baseline from the week before launch: top organic landing pages, a small set of priority keywords, and the most linked-to URLs. You’ll compare everything against this.

Weekly checks (do these on both domains)

Run the same routine every week for the first month, then every other week until day 90:

• Index coverage and crawl errors: watch for spikes in “Not found (404)”, redirect errors, or sudden drops in indexed pages.
• Top linked pages: confirm each one lands on the intended new page (not the homepage) after one clean redirect.
• Rankings: track a small set of queries tied to the moved product/region plus a few brand queries.
• Organic landing pages and traffic: compare which pages are getting visits now vs before.
• Redirect chains and 404s: find “A to B to C” redirects, loops, and any old URLs returning 404.

Then look at the story the data tells. For example, if your old “/pricing” was heavily linked and now redirects to a generic “/plans” page, but rankings fall and time on page drops, that’s a sign the destination doesn’t match intent. Fixing the target page often restores performance faster than waiting.

Red flags that deserve same-day fixes

Treat these as urgent:

• A top linked page redirects to the homepage or an unrelated category
• Many 404s on URLs that used to get links or traffic
• A sudden rise in indexed old-domain URLs that should be redirected
• Chains longer than one hop for important URLs

Next steps: stabilize, then rebuild authority on the new domain

After a split, the first job is stability. Keep things steady long enough for Google and users to learn the new “shape” of your site. Then push growth.

A simple timeline:

• Pre-launch (1-2 weeks before): freeze big content changes, confirm your redirect map is final, and make sure the new domain has clean indexable pages (no accidental noindex, no blocked folders). Do one last pass to ensure key pages on the new domain have the right internal links pointing to them.
• Launch week: ship redirects, update internal links, and watch the basics daily (crawl errors, redirect loops, sudden traffic drops, pages getting indexed on the wrong domain). Expect some ranking wobble.
• Weeks 2-4: fix patterns, not one-off issues. Expand redirect coverage where needed, replace homepage redirects with specific matches, and keep content mostly steady while signals settle.
• Months 2-3: once indexing looks stable, start improving pages again (content, UX, speed). This is also when you can safely test new internal link paths and add new pages on the new domain.

Keep “catch-all” redirects only as temporary safety nets, then replace them with page-level redirects once you confirm what people and bots actually hit. And if a partner site links to an old URL months later, don’t panic - leave those redirects working long-term so late links still pass value to the new site.

Even with clean redirects and canonicals, a new domain often needs fresh signals. If you’re planning to add premium backlinks after the move, do it after your split is stable so those links strengthen the right pages. For teams that want a more direct path to placements on authoritative sites, SEOBoosty (seoboosty.com) is one option: you select domains from a curated inventory and point the backlink to the specific new-domain pages you’re trying to rank.