Migrating ccTLDs to Subfolder Structures

Problem Statement

Running example.de, example.fr and example.co.uk as separate country-code domains means running separate estates: each accumulates its own authority, each needs its own certificates and its own Search Console property, and a link earned by one does nothing for the others. Consolidating them into example.com/de/, /fr/ and /uk/ pools that authority — which is usually the reason for the move — but it is also several domain migrations happening at once, each with its own redirect map, its own index transition, and its own market that will notice if it goes wrong. This page sits under International & hreflang Migrations and covers sequencing the consolidation so the markets move one at a time.

When to Use This Approach

  • Several country-code domains serve the same brand with substantially overlapping content.
  • Smaller markets underperform because they cannot draw on the authority of the largest.
  • The operational cost of separate certificates, properties and deployments has become significant.
  • You are willing to trade an explicit geographic signal for shared authority.
  • Each market can be moved and observed independently rather than all at once.

Step-by-Step Instructions

1. Decide Whether Consolidation Is Actually Right

A country-code domain is a strong, unambiguous geographic signal and it carries market recognition that a subfolder does not. Consolidation is usually correct where the markets share content and the smaller ones are starved of authority, and usually wrong where each market has genuinely distinct content, a local brand, or a regulatory requirement to be locally hosted and locally named. Make the decision on those grounds rather than on operational convenience alone, because the move is expensive to reverse.

Model the downside honestly before committing. Each ccTLD being retired will pass through the same index transition as any domain change — a dip, then a recovery over weeks — and it will do so per market. Consolidating five domains means five of those transitions, and if they all happen in one weekend the aggregate dip is what leadership sees.

2. Choose the Subfolder Scheme Before Moving Anything

Decide whether folders represent language, country, or both, and apply the answer consistently. /de/ meaning German-language and /de-at/ meaning Austrian German is coherent; a mixture of language folders for some markets and country folders for others is not, and it produces annotation sets that nobody can reason about later. Write the scheme down and generate every mapping from it.

Reserve the root for something deliberate. Serving the primary market from / while everything else sits in a folder creates an asymmetry that complicates annotations and geographic logic; moving every locale into a folder and leaving the root as a language selector is cleaner, at the cost of one extra redirect for your largest market.

3. Migrate One Market at a Time

Move the smallest market first, observe it fully through its index transition, and only then move the next. This is the single most valuable decision in the whole exercise: it bounds the blast radius, it lets you learn the shape of the transition on a market where the cost of being wrong is lowest, and it means an aggregate traffic chart never shows five simultaneous dips.

Keep each retired domain answering throughout. The ccTLD must continue to serve 301s to its new subfolder for years, not months — inbound links from local partners, directories and press in that market are the least likely of all your links to be updated, and the domain itself often carries recognition that outlives its use as a serving host.

Sequence the markets by value rather than by convenience, and be explicit that the ordering is deliberate. The temptation is to move the market whose team is most available or whose content is simplest; the useful ordering is ascending by what you lose if the transition goes badly. That usually puts the largest revenue market last, by which point you have run the process several times and know exactly what its transition should look like week by week.

4. Rebuild the Annotation Graph Around the New Structure

Every set changes at once, because every member’s URL changes when its market moves. Regenerate the whole graph from the mapping as described in Updating hreflang Sets After a Domain Change, and be careful during the staged rollout: while some markets are on ccTLDs and others are in folders, each set legitimately contains a mixture, and the annotations must reflect the current reality rather than the end state.

5. Hand Over the Search Console Properties

Each ccTLD is a separate property with its own history and its own Change of Address filing. File one per retiring domain, pointing at the consolidated host, and follow the process in Search Console Handover. Export each property’s performance history before its retention window rolls past the migration, because that data is the only basis on which anyone will later be able to judge whether the consolidation worked.

What consolidation trades away and what it buys Country-code domains and locale subfolders compared across authority pooling, geographic signalling, operational overhead and migration cost. Shared authority, in exchange for an explicit signal Property Separate ccTLDs Locale subfolders Authority separate per market pooled across all Geographic signal strong and automatic must be stated explicitly Certificates and properties one set per market one set total Local brand recognition high reduced Cost to reverse n/a very high The last row is why this decision deserves modelling rather than a preference: unwinding a consolidation means migrating every market again.
Consolidate where smaller markets are starved of authority; stay separate where each market is genuinely its own business.

Worked Example

A manufacturer runs example.de, example.fr, example.it and example.com, with the German and French sites performing well and the Italian one barely ranking. They consolidate into example.com/de/, /fr/ and /it/, moving Italy first because it has the least to lose.

The Italian transition takes nine weeks: a 30% dip in the third week, recovery to baseline by week seven, and by week ten Italian traffic is 40% above its pre-migration level as it begins drawing on the consolidated authority. Only then do they move France, and a month later Germany.

$ curl -sIL https://example.it/prodotti/widget | grep -E '^HTTP|^location'
HTTP/2 301
location: https://example.com/it/prodotti/widget
HTTP/2 200

Had all three moved together, the aggregate chart would have shown one large dip with no way to distinguish a market that was recovering normally from one that was not — and no opportunity to apply what the first transition taught them to the second.

Moving markets one at a time The smallest market migrated and observed through a full index transition before the next is moved, so each transition is attributable and the aggregate never shows several dips at once. Smallest market first, and observe it fully Smallest market lowest cost to be wrong Full soak watch the whole transition Apply lessons to the next market Largest last with everything learned Moving every market in one weekend produces a single aggregate dip in which no market can be distinguished from any other. Staging also means the annotation graph legitimately contains mixed hosts for a period — generate it from current reality, not the end state.
Each transition takes weeks, so a staged rollout is measured in months — which is the real cost of bounding the risk this way.

Set an expectation for the shape of each transition before the first market moves, and hold every subsequent market to the same curve. Once you have observed one full transition you have a baseline that is far more useful than any general guidance — a market that is tracking the first one is fine, and a market that diverges from it is worth investigating while the divergence is still small.

Verification

Confirm each market individually, at each stage of the staged rollout.

# 1. Every legacy ccTLD path resolves to its subfolder in a single hop
for u in https://example.it/prodotti/widget https://example.it/chi-siamo; do
  printf '%s -> ' "$u"
  curl -sIL -o /dev/null -w '%{num_redirects} hops, %{http_code}, %{url_effective}\n' "$u"
done

# 2. Annotations reflect the current mixture, not the end state
curl -s https://example.com/it/prodotti/widget | grep -o 'hreflang="[^"]*" href="[^"]*"'

# 3. The retired domain still resolves and still holds a valid certificate
curl -sI https://example.it/ | head -1

A clean result is one hop to a 200 for every legacy path, an annotation set naming the correct current URL for each market whether folder or ccTLD, and a legacy domain that is still healthy rather than merely still registered.

Per-market obligations that outlive the switch Four commitments that persist after a ccTLD is retired — the domain registration, the redirects, the certificate and the Search Console property — with how long each must be maintained. Retiring the host is not retiring the domain Obligation Maintain for If dropped early Domain registration years — indefinitely if possible anybody can re-register it 301s to the subfolder years inbound links become 404s Valid TLS certificate as long as the redirects run the redirect is unreachable Search Console property keep verified indefinitely lose the history and the filing The certificate row is the one most often forgotten: a redirect served over a failed handshake is a redirect nobody receives.
All four are cheap to maintain and expensive to reinstate, which makes deliberate retirement dates worth scheduling rather than drifting into.

FAQ

Does moving from a ccTLD lose the geographic signal entirely? It loses the strongest automatic one and replaces it with signals you provide explicitly: the hreflang annotations, the language of the content, local currency and address details, and the subfolder itself. In practice that combination is sufficient for most estates, which is why the consolidation is common — but it is a real trade, and a market that ranks partly because it is on a local domain will be relying on weaker signals afterwards.

How long should the retired ccTLDs stay registered? Indefinitely if the budget allows, and certainly for years rather than months. Two things depend on it: the redirects that carry inbound links, and the fact that an expired domain carrying your brand can be re-registered by anybody. The registration cost is trivial against either risk, and letting a recognisable market domain lapse is one of the few genuinely irreversible steps in this process.

Can I keep some markets on ccTLDs and consolidate others? Yes, and it is a legitimate end state rather than merely a transitional one — a market with a distinct local brand or a hosting requirement can reasonably stay separate while the rest consolidate. What it costs is uniformity: the annotation sets contain mixed hosts permanently, and anybody reasoning about the estate later has to know which markets are which. Document the exception and its reason.

Should the consolidation and a platform migration happen together? No, where the schedule allows separating them. Each is a substantial change with its own failure modes, and combining them means that when a market degrades you cannot tell whether the cause was the structure change or the infrastructure change. Move the platform first with the ccTLDs intact, soak, then consolidate market by market.

What happens to the Search Console history for each retired domain? It stays with that property and does not transfer, exactly as with any domain change. Export the performance data for each ccTLD before its sixteen-month retention window passes the migration date, keep each property verified rather than deleting it, and file a Change of Address per domain. The exports are what make a year-on-year comparison possible once several markets have moved.

Should the subfolder use a language code or a country code? Whichever matches how the content actually differs, and then consistently. If the German and Austrian sites are the same content, a language folder is honest and a country folder implies a distinction that does not exist; if they carry different pricing, stock and legal text, country folders describe reality. The failure to avoid is mixing the two conventions across markets, which leaves nobody able to predict a URL from a market name or vice versa.

Related

← Back to International & hreflang Migrations