A two-phase technical SEO transition for iblaursen.dk — giving each language its own URL identity, then internationalizing to iblaursen.com.
The business case, expected outcomes, and strategic rationale in plain language.
Ib Laursen currently serves Danish, English, and German customers from the same website addresses. A Danish product page and its English equivalent share an identical URL — meaning search engines such as Google can only index one version, and that version is almost always the Danish one. English and German customers searching in their own language are effectively invisible to Google's results pages for those markets.
This plan resolves that invisibility in two steps: first by giving each language its own unique web address on the existing domain, and then by moving the entire site to a new international domain (iblaursen.com) structured specifically for global audiences. The two steps are deliberately kept separate to protect the organic search traffic the site already earns.
Google can now crawl, index, and rank the Danish, English, and German versions of every product page independently. Each language competes in its own market rather than all three competing for a single URL slot.
iblaursen.com with /da/, /en/, and /de/ subdirectories sends the correct geo and language signals to Google for all three markets simultaneously — the industry-standard structure for international e-commerce.
By separating the two changes and waiting for Google to fully process Phase 1 before beginning Phase 2, the site avoids the 44–50% organic traffic losses documented when domain moves and URL changes are combined.
The Cost of Combining Both Changes at Once
Industry data consistently shows that changing both the URL structure and the domain simultaneously — without a stabilization window — results in a 44–50% temporary loss of organic traffic. For a site already showing a −26.5% traffic decline in the current Ahrefs data, absorbing a further 44–50% drop would be commercially damaging. The phased approach is not a preference — it is a risk management requirement.
Understanding why the current structure makes URL localization technically complex — and why it cannot be done with a simple find-and-replace.
Single URL — serves all three languages
iblaursen.dk/produkter/lys-stager.htmlA URL rewrite is a server-level instruction that redirects one address to another. It works when a single piece of content needs a new address. The problem here is fundamentally different: the same URL currently delivers three different pieces of content depending on which language the visitor has selected.
Rewriting /produkter/lys-stager.html to /products/candles-holders.html would only move one version — and it would break the other two. There is no server rule that can simultaneously redirect the same URL to three different destinations based on language preference, because the language preference is stored in the user's session, not in the URL itself.
The Technical Constraint
Because the language is determined by session state rather than the URL, the server cannot know which of the three language versions to redirect to when it receives a request for the current shared URL. A rewrite rule would have to pick one language and break the other two.
The Required Solution
Each language version must be built as a genuinely separate page with its own unique URL. The content management system must publish three distinct pages per product category — one per language — before any redirects can be configured.
For every one of the 41 URLs in the current sitemap, Phase 1 results in three separate, independently addressable content pages. This is not duplication — it is the correct technical architecture for a multilingual site. Each page contains language-specific content and is linked to the others via hreflang tags so Google understands they are translations of the same product category.
Before Phase 1
/produkter/lys-stager.html1 URL · 3 languages · 1 indexed page
After Phase 1
3 URLs · 3 languages · 3 independently indexed pages
The Danish URL remains completely unchanged. Existing Danish rankings, backlinks, and indexed pages are preserved. Only two new pages are added per URL — the English and German versions. The old shared URL continues to serve Danish content and receives a redirect from any legacy English or German paths that previously pointed to it.
The sequence is not arbitrary. Each decision is driven by how Google processes large-scale site changes.
There are two major changes required to reach the final desired state: (1) language-specific URL paths and (2) a new international domain. Both could theoretically be done at the same time. They are not, for a specific reason.
Google's crawlers process site changes incrementally. When a large number of URLs change simultaneously, Google must re-evaluate every affected page from scratch — re-crawling, re-indexing, and re-assessing relevance signals. If the domain also changes at the same time, Google must additionally transfer all historical trust signals from the old domain to the new one. Combining these two workloads creates a compounding uncertainty that consistently produces significant temporary ranking losses across all affected pages.
The .dk domain has years of accumulated trust with Google — 403 referring domains and a known crawl history. Introducing new URL paths on a domain Google already understands is far less disruptive than introducing them simultaneously with a domain change.
By launching Phase 1 on iblaursen.dk, the new English and German URLs inherit the domain's existing trust immediately. Google begins indexing them with a head start rather than treating them as entirely new, unknown pages.
Any ranking disruption from the URL changes is contained to the URL structure only. The domain authority is not in question, which limits the recovery time.
Google does not process all URL changes instantly. A full re-crawl and re-indexing cycle for a site of this size typically takes 4–8 weeks. Starting Phase 2 before this cycle completes would mean moving the domain while Google is still mid-process on Phase 1 — stacking two incomplete migrations on top of each other.
The stabilization criteria are measurable: all new EN and DE URLs must appear as 'Indexed' in Google Search Console, hreflang errors must be zero, and organic traffic to the new language stores must have returned to or exceeded pre-Phase-1 levels.
At this point, Google has already indexed all three language versions of every page on iblaursen.dk. The domain migration is now a single, clean operation: move known, indexed pages from one domain to another via 301 redirects.
The .com gTLD sends no country-specific signal, making it the correct domain for a site serving multiple international markets. The .dk ccTLD, by contrast, signals Denmark-only relevance to Google — a structural disadvantage for English and German market visibility.
Google's Change of Address tool in Search Console is used to formally notify Google of the domain transfer, accelerating the re-attribution of historical trust signals from .dk to .com.
In summary: Phase 1 is done first because it is safer to change URLs on a trusted domain than on a new one. Phase 2 is done second because it is safer to move a domain whose URL structure is already stable and indexed than one that is mid-migration. The stabilization window exists because Google needs time to finish processing Phase 1 before Phase 2 introduces a second major change signal.
Publish three separate content pages per URL with language-translated slugs. Implement hreflang and 301 redirects. Remain on iblaursen.dk throughout.
Existing pages
No URL changes. Danish content and rankings are fully preserved.
No action required on existing DA pages
New pages published
English content is published at new English-language URL slugs. These are brand-new pages from Google's perspective.
Publish 41 new EN pages with translated slugs
New pages published
German content is published at new German-language URL slugs. These are brand-new pages from Google's perspective.
Publish 41 new DE pages with translated slugs
Total new pages created in Phase 1: 82 (41 English + 41 German). The 41 existing Danish pages are untouched. After Phase 1, the site has 123 language-specific pages where it previously had 41 shared ones. Each page is connected to its translations via hreflang tags — see the Hreflang section for details.
Once the new English and German pages are live and indexed, 301 permanent redirects are configured for any legacy paths that previously served those language versions. This ensures that any external links pointing to old shared URLs pass their value to the correct new language-specific page, and that users who bookmarked old URLs land on the right content.
Phase 1 → Phase 2 Gate: Stabilization Criteria
Phase 2 must not begin until all four of the following are confirmed in Google Search Console and analytics:
The following examples are drawn from the current sitemap to show how the URL translation pattern applies across different content types. The full URL mapping will cover every page on the site — these examples demonstrate the naming logic and structure.
Top-level category
The root product listing page — the broadest category slug is translated in full.
Candles & holders
The example used throughout this plan. Both the category name and the descriptor are translated independently.
Kitchen sub-category
Multi-word slugs are hyphenated and translated word-for-word. Compound nouns in German are joined without hyphens where natural.
Brand page (untranslated)
Registered brand names (Mynter, Altum R, Stillenat R) are never translated — only the parent path segment changes language.
Seasonal / campaign page
Seasonal terms are translated to their market-native equivalents. 'Påske' becomes 'Easter' in English and 'Ostern' in German.
These examples are illustrative only. The sitemap currently lists a subset of the full site. The complete URL mapping exercise — covering every indexable page — must be completed as the first step of Phase 1, before any redirects or new pages are published. Toggle between Phase 1 and Phase 2 above to see how the same URL evolves across both migrations.
Hreflang tags are the technical mechanism that connects the three language versions of each page. Without them, Google may treat the new pages as duplicate content rather than translations.
When Phase 1 creates three separate pages for each product category, Google needs to understand that /produkter/lys-stager.html, /products/candles-holders.html, and /produkte/kerzen-halter.html are translations of the same content — not three competing pages about the same topic. Hreflang tags, placed in the HTML of every page, provide this signal.
Google uses this information to serve the correct language version to users based on their browser language and location settings. Without hreflang, a German user searching in German might be shown the Danish version of a page — or Google might consolidate all three into a single result, defeating the purpose of the localization entirely.
Each of the three language pages carries identical hreflang tags pointing to all three versions. The x-default tag designates the English version as the fallback for users whose language is not explicitly listed.
<link rel="alternate" hreflang="da" href="…dk/produkter/lys-stager.html" /> <link rel="alternate" hreflang="en" href="…dk/products/candles-holders.html" /> <link rel="alternate" hreflang="de" href="…dk/produkte/kerzen-halter.html" /> <link rel="alternate" hreflang="x-default" href="…dk/products/candles-holders.html" />
All hreflang tags are updated to reference the new .com URLs with ISO 639 language prefixes. The structure is identical — only the domain and path prefix change.
<link rel="alternate" hreflang="da" href="…com/da/produkter/lys-stager.html" /> <link rel="alternate" hreflang="en" href="…com/en/products/candles-holders.html" /> <link rel="alternate" hreflang="de" href="…com/de/produkte/kerzen-halter.html" /> <link rel="alternate" hreflang="x-default" href="…com/en/products/candles-holders.html" />
Tags must be reciprocal
If the English page points to the Danish page, the Danish page must point back to the English page. One-directional tags are silently ignored by Google.
Every page must reference itself
Each page must include a hreflang tag pointing to its own URL, in addition to all other language variants.
URLs must be fully qualified
All hreflang href values must include the full domain (https://). Relative paths are not supported.
x-default for unmatched languages
The x-default tag designates the fallback page for users whose browser language does not match any listed variant. Set English as x-default for international reach.
Never canonicalize across languages
Canonical tags must point to the same-language version only. Setting a German page's canonical to the Danish page would tell Google to ignore the German version entirely.
All referenced URLs must return 200
Any hreflang URL that redirects or returns a 404 causes the entire tag set for that page to be ignored. All URLs must be live before hreflang is deployed.
Canonical tags work alongside hreflang to tell Google which URL is the authoritative version of a page. They are especially important during this migration because the same content temporarily exists at multiple addresses.
A canonical tag is a single line in the HTML of a page that says: "This URL is the definitive version — consolidate all ranking signals here." Without it, Google must guess which of several similar URLs to treat as the primary one. In a migration that creates new pages, changes domains, and runs two environments in parallel, the risk of Google making the wrong guess is high.
The core rule is simple: every page's canonical tag must point to itself — its own full URL, including domain and path. A page must never canonicalize to a different language version, and during Phase 2 the old .dk pages must not canonicalize to the new .com pages (or vice versa) while both are live. Cross-domain canonicals used incorrectly are one of the most common causes of traffic loss in domain migrations.
Currently, /produkter/lys-stager.html serves Danish, English, and German content depending on the user's session language. From Google's perspective, this is a single URL with a single canonical — but it is actually three different pages sharing one address. Google cannot distinguish between them, so it indexes only one version and treats the others as invisible.
Phase 1 resolves this by giving each language its own URL. At that point, a proper self-referencing canonical can be set on each page for the first time. Until Phase 1 is complete, canonical tags cannot be used to differentiate language versions — there is simply no unique URL to point to.
Each of the three language pages carries a canonical pointing to its own URL. This is the first time Google can distinguish between the three versions as separate, authoritative pages.
The Danish page's canonical points to the Danish URL. The English page's canonical points to the English URL. They are independent — never cross-referencing each other.
Once pages are live on the new domain, each page's canonical is updated to reference its own .com URL. The .dk pages remain live with 301 redirects — their canonicals are not changed, as Google will follow the redirect and consolidate authority to the .com destination.
Do not set the .dk pages to canonicalize to .com while both are live. The 301 redirect is the correct signal — adding a cross-domain canonical on top creates a conflicting instruction that can confuse Googlebot.
Always self-referencing
Every page's canonical tag must point to its own full URL. This applies to all three language versions independently, in both Phase 1 and Phase 2.
Canonical and hreflang must agree
The URL in a page's canonical tag must match the URL used for that language in the hreflang tag set. Mismatches cause Google to distrust both signals.
Use absolute URLs
Canonical tags must include the full domain (https://www.iblaursen.dk/…). Relative paths are not supported and will be ignored by Google.
Canonical must return HTTP 200
The URL in a canonical tag must be a live page returning a 200 status code. A canonical pointing to a 301 or 404 is treated as absent — no consolidation occurs.
Never canonicalize across languages
Setting the English page's canonical to the Danish URL tells Google the English page does not exist as an independent entity. All ranking signals for the English page are discarded.
Never cross-domain canonical during live migration
While both .dk and .com are serving live pages, do not set .dk canonicals to .com URLs. Use 301 redirects as the consolidation signal — not canonicals.
Do not remove .dk canonicals prematurely
If the .dk pages lose their canonical tags before the .com pages are fully indexed, Google may temporarily treat .dk content as canonical again, splitting link equity.
Staging must block indexing — not canonicals
During development and QA, block staging pages with robots.txt or noindex — not by pointing their canonicals to production. Canonical-based staging blocks are unreliable and risk leaking signals.
Canonical and Hreflang: Complementary, Not Interchangeable
Hreflang tells Google which language audience each page is for. Canonical tells Google which URL is the authoritative address of that page. Both signals must be present and consistent. A page with correct hreflang but no canonical may still be consolidated with a duplicate. A page with a correct canonical but no hreflang may be served to the wrong language audience. The two tags solve different problems and must be implemented together.
Move the fully-indexed, language-separated site from iblaursen.dk to iblaursen.com with ISO 639-1 language subdirectories.
The ISO 639-1 subdirectory structure (/da/, /en/, /de/) is Google's recommended approach for multilingual sites on a single domain. It consolidates all domain authority under one root while giving each language a clearly separated section of the site.
When Phase 2 launches, the Phase 1 redirect rules must be updated to point directly to the final .com URLs. If they are left pointing to the Phase 1 .dk URLs, which then redirect to .com, a two-hop redirect chain is created. Each hop in a redirect chain reduces the amount of link equity passed to the final destination — and chains longer than two hops are frequently not followed by search engine crawlers at all.
✗ WRONG — Two-hop chain (link equity lost at each hop)
✓ CORRECT — Single hop (full link equity passed)
Google Search Console provides a formal Change of Address tool that notifies Google of an intentional domain migration. Submitting this accelerates the transfer of historical trust signals from iblaursen.dk to iblaursen.com. It requires that 301 redirects are already in place and that the destination property (iblaursen.com) is verified in GSC before submission.
A structured 6-month schedule to detect and resolve issues before they cause lasting ranking damage.
| Timeframe | Action | Tool |
|---|---|---|
| Day 1–7 | Monitor crawl errors and coverage drops daily | Google Search Console |
| Day 1–7 | Verify 301 redirects are resolving correctly for all 41 mapped URLs | Screaming Frog |
| Day 1–7 | Confirm hreflang tags are being parsed without errors | GSC International Targeting |
| Week 2–4 | Track organic traffic by language store vs. pre-migration baseline | Google Analytics 4 |
| Week 2–4 | Monitor keyword ranking changes for top 50 priority terms | Semrush / Ahrefs |
| Month 2–3 | Audit backlink profile for broken links pointing to old URLs | Ahrefs |
| Month 3–6 | Confirm full index migration from .dk to .com in GSC | Google Search Console |
| Ongoing | Keep all .dk → .com redirects live permanently | Server configuration |
Redirect permanence is not optional. The 301 redirects from iblaursen.dk to iblaursen.com must remain active indefinitely. Removing them at any point in the future — even years later — will result in a permanent loss of all historical link equity that was accumulated on the .dk domain and transferred to .com.
Track migration progress. State is saved automatically in your browser.