Your shopping cart is empty!
International SEO goes well beyond hreflang. The right URL structure, geotargeting in GSC, genuinely localised content, and a globally distributed CDN together decide whether your target audience can actually find you in every country you operate in.
Contents
- What international SEO actually covers
- URL structure: ccTLD, subdomain, or subfolder
- Hreflang: implementing it correctly
- Geotargeting in Google Search Console
- Localisation vs translation
- IP geolocation and redirects
- CDN for international sites
- Common international SEO mistakes
- Technical checklist
- FAQ
What international SEO actually covers
Most teams launching internationally set up hreflang and call it done. In reality, hreflang is just one node inside a much larger system. International SEO spans URL architecture, technical signals that tell Google which countries and languages each version targets, genuine content localisation, performance for geographically distributed users, and duplicate management across language versions.
The single most common reason we see international launches fail is when a company adds, say, a German-language version of its site but forgets to configure geotargeting in GSC and skip connecting a CDN node in Germany. Google can see the pages but has no clear signal about who they are for, and German users get a slow site that can't compete in local SERPs.
The core components of a solid international SEO system:
- URL structure — ccTLD, subdomain, or subfolder
- Hreflang — language and region signal to the search engine
- Geotargeting in GSC — explicit country assignment
- Content localisation — adaptation to real search intent in each market
- IP geolocation — routing users to the right version
- CDN — fast load times in every target region
International SEO is not translating your site. It is rebuilding the search experience for each market from the ground up.
URL structure: ccTLD, subdomain, or subfolder
This is the first and most consequential architectural decision. It determines how Google distributes authority between versions, how much resource the structure demands to maintain, and how strong a geo-signal each version sends.
Comparing the three approaches
| Factor | ccTLD (example.de) | Subdomain (de.example.com) | Subfolder (example.com/de/) |
|---|---|---|---|
| Geo-signal strength | Strongest | Medium | Weaker (GSC compensates) |
| Domain authority | Separate per TLD | Partially shared | Fully shared |
| Implementation complexity | High | Medium | Low |
| Maintenance cost | High (N domains) | Medium | Low |
| Link building | Separate per TLD | Partially shared | Shared |
When ccTLD makes sense
ccTLD is the right call when you are entering a market with strong local competition and you have the resources to run separate link building and a dedicated technical team for each domain. Launching a large e-commerce brand across Germany (.de), France (.fr), and Poland (.pl) simultaneously is a defensible choice. But for a five-person startup that same architecture becomes a liability.
Why subfolders win for most projects
Subfolders (example.com/de/, example.com/fr/) pool authority from the main domain and are by far the simplest to deploy. The geo-signal is weaker than ccTLD, but it is offset by correct GSC geotargeting and hreflang. For most SaaS products, agencies, and media sites this is the right starting point — you can always migrate to ccTLD later if the market demands it.
Rule of thumb: If your link-building budget is constrained, go with subfolders. One strong domain beats five weak ones every time.
Subdomains: a justified middle ground?
Subdomains (de.example.com) are primarily used by large platforms where different language versions run on separate CMS instances or are maintained by different teams. Google treats subdomains as partially separate sites, so authority transfer is incomplete. Unless a technical constraint forces your hand, a subfolder is usually the better choice.
Hreflang: implementing it correctly
Hreflang tells Google which version of a page is intended for which language and region. Studies consistently show that more than 50% of hreflang implementations contain errors that eliminate most of the benefit.
Where to place hreflang annotations
There are three valid locations. Use only one — do not mix methods:
- In the <head> of each page — most common, works with virtually every CMS
- In an XML sitemap — practical for large sites (100k+ pages) where adding head tags is impractical
- In HTTP headers — only for non-HTML files such as PDFs
Hreflang syntax
Every page must reference all language versions, including itself. Use x-default for a language-neutral fallback URL:
<link rel="alternate" hreflang="uk" href="https://example.com/uk/page/" /> <link rel="alternate" hreflang="ru" href="https://example.com/ru/page/" /> <link rel="alternate" hreflang="en" href="https://example.com/en/page/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/en/page/" />
Non-negotiable hreflang requirements
These are the most frequent causes of hreflang failure — check them first in any audit:
- Return links (bidirectional confirmation) — if page A references B, B must reference A
- Absolute URLs — relative links are not processed correctly
- ISO 639-1 language codes — uk, ru, de, fr, en
- ISO 3166-1 Alpha-2 country codes — gb (United Kingdom), ua (Ukraine), us (United States) for regional targeting
- Canonical aligned with hreflang — each version's canonical must point to itself, not to another version
Common trap: hreflang="en-GB" targets English speakers in the UK. hreflang="en-US" targets the US. hreflang="en" (no country suffix) serves as a generic English fallback. These are not interchangeable.
For a deep-dive on implementation, see our dedicated hreflang setup guide.
Geotargeting in Google Search Console
GSC lets you explicitly tell Google which country a given version of your site targets. This is especially important for subfolders and subdomains, where Google cannot automatically infer geography from the domain structure.
Step-by-step geotargeting setup
The setting is configured separately for each language version — do not apply it at the root domain level.
- Add each site version as a separate GSC property (for subfolders use URL-prefix type, e.g.
https://example.com/de/) - Verify ownership of each property
- Navigate to: Legacy tools and reports → International Targeting → Country tab
- Select the target country from the dropdown
- Save the setting
Note: For ccTLDs (.de, .fr, .pl, etc.) geotargeting in GSC is unnecessary — Google infers the country from the TLD automatically. Only configure it for subfolders and subdomains.
Ongoing GSC monitoring by market
Once your international versions are live, review these GSC reports monthly for each market:
- Performance → Countries — track whether impressions and clicks are growing in target countries
- Coverage — watch for indexing errors specific to individual language versions
- International Targeting — monitor any hreflang errors Google surfaces
For a full walkthrough of GSC, see our complete Google Search Console guide.
Localisation vs translation
This is one of the most important and consistently underestimated dimensions of international SEO. A high-quality translation still produces poor SEO results if your target audience searches with entirely different terms, phrasing, or intent than the source market.
Translation versus localisation — the key difference
| Translation | Localisation |
|---|---|
| Converts text between languages | Adapts the entire experience for the market |
| Preserves source structure | Restructures content around local context |
| Uses the same keywords (calque translation) | Researches native search queries for the target market |
| Same currency, units, examples | Local currency, local metrics, cultural references |
| Fast and inexpensive | Requires a native speaker with market knowledge |
A concrete example
Suppose you are promoting SEO services in Poland. A literal translation of "website promotion" gives you "promocja strony". But Polish users predominantly search for "pozycjonowanie stron" or "SEO Warszawa". Content built around the calque translation will not rank for the queries that actually drive business. This is the fundamental problem with translation-only approaches.
Content localisation checklist
- Native-language keyword research using Ahrefs or Google Keyword Planner set to the target country
- Adapted CTAs — phrasing and tone that resonate with local buyers
- Local case studies and examples from recognisable companies in that market
- Local currency and pricing where relevant
- Date formats — DD/MM/YYYY vs MM/DD/YYYY
- Legal requirements — GDPR, cookie consent, local data laws
- Native editorial review — a fluent speaker checks for naturalness, not just accuracy
E-E-A-T for international versions: Add local trust signals — a local phone number, a physical address in-country, and reviews from local clients. These matter for both rankings and conversion rates.
IP geolocation and redirects
IP geolocation lets you automatically route users to the appropriate language version based on their location. Getting this right from an SEO perspective is more nuanced than it looks.
Why automatic IP redirects are risky
If you redirect all visitors from a specific country's IP addresses to the local version, you are likely blocking Googlebot from crawling certain versions of your site. Googlebot primarily crawls from US IP addresses and may never reach your Polish version if it hits an IP-based redirect every time.
The right approach
- Do not apply hard 301/302 redirects based on IP without a bot-exclusion mechanism
- Use a JavaScript-driven suggestion banner ("It looks like you're in Germany — switch to our German site?") instead of a forced redirect
- If a redirect is essential — ensure all versions remain accessible at their direct URLs without redirection
- Persist language preference in a cookie so users are not re-redirected on their next visit
Google's own documentation is explicit: automatic IP-based redirects complicate crawling and can prevent indexing. Offer users a choice rather than imposing a version on them.
IP geolocation and hreflang working together
IP geolocation and hreflang are separate mechanisms running in parallel. Hreflang tells Google which version to surface in the SERP for a given user. IP geolocation controls which version the user lands on after clicking. They must be aligned: if hreflang directs German users to /de/, the geolocation redirect should route to /de/ as well.
CDN for international sites
Core Web Vitals (LCP, INP, CLS) are assessed separately by country. A site that loads in 1.2 seconds in Western Europe can take 4–5 seconds in Brazil or Southeast Asia if the origin server sits in Frankfurt. From Google's perspective that means poor CWV — and lower rankings — specifically in those markets.
How a CDN addresses this
A Content Delivery Network caches static assets at edge nodes distributed around the globe. A user in Tokyo fetches files from the nearest Asian PoP rather than waiting for a round-trip to Frankfurt. The result is a sharp reduction in TTFB and meaningfully better LCP scores in every region — which directly affects your rankings in those markets.
What to look for when choosing a CDN
- PoP coverage in your target countries — verify the provider has edge nodes in every region you compete in
- Edge computing capability — ability to run redirect logic and hreflang serving at the CDN layer
- HTTP/3 and QUIC support — significant gains on mobile networks in emerging markets
- CMS integration — available plugins or modules for your platform
Common CDN choices for international sites
- Cloudflare — the most widely used, free plan covers basic needs, 300+ edge locations globally
- AWS CloudFront — well-suited to complex architectures already on AWS infrastructure
- Fastly — powerful programmable edge logic for advanced use cases
- BunnyCDN — cost-effective with solid global coverage
For the technical details of performance optimisation, see our guide on Core Web Vitals: LCP, INP, and CLS.
Common international SEO mistakes
After auditing dozens of multi-regional sites, the same mistakes come up repeatedly. Here are the costliest ones:
1. Duplicate content across language versions
If your /de/ and /fr/ pages are near-identical translations with only the language swapped, you are creating a duplicate content problem and leaving significant ranking potential on the table. The fix is localised content — differences that go beyond language to include local keywords, examples, and structure.
2. Broken or one-sided hreflang chains
If page A references page B via hreflang but B does not reference A, Google ignores the entire annotation. Validate your hreflang chains after every significant site update — they break more often than you'd expect.
3. Canonical pointing to a different language version
One of the most damaging errors. If your German version carries a canonical pointing to the English version, Google will not index the German version. Every language version must have a self-referencing canonical. See our canonical tag guide for the full picture.
4. A single sitemap for all versions with no hreflang annotations
Submitting all language versions in one undifferentiated sitemap wastes the opportunity to declare cross-version relationships to Google. Use either separate sitemaps per language or a correctly annotated combined sitemap.
5. Ignoring local search engines
Google is not the dominant search engine everywhere. Baidu owns over 60% market share in China. Seznam matters in the Czech Republic. If these are your target markets, international SEO must account for platform-specific requirements beyond Google's guidelines.
6. IP geolocation blocking Googlebot
Covered above — forced IP-based redirects are one of the hardest indexing problems to diagnose because the site appears to work fine when you check it manually from your location.
7. No local link building
A technically perfect international site will not rank in a new market without links from locally authoritative sources. Google assesses authority at a regional level: links from German news sites carry more weight for German rankings than American ones. Read our guide on link-building strategy for multi-regional projects.
Technical checklist for multi-regional websites
Run through this list before launching a new language version or auditing an existing one. It is grounded in Google's official international SEO documentation and the practical experience of our team.
Architecture and structure
- URL structure chosen (ccTLD / subdomain / subfolder) and matched to team resources
- Every version accessible at a stable URL independent of cookies or JavaScript
- Robots.txt does not block any language version
- Sitemap includes all language versions with hreflang annotations (or separate sitemaps per language)
Hreflang
- Hreflang present on every page of every language version
- Return links verified — every version references all others
- x-default declared for the language-neutral fallback URL
- Correct ISO 639-1 / ISO 3166-1 codes used throughout
- All URLs are absolute with protocol and domain
- Validated with Screaming Frog or equivalent after each deployment
GSC and geotargeting
- Each version added as a separate GSC property
- Geotargeting configured for subfolders and subdomains
- Performance monitored separately for each market
Content and localisation
- Keywords researched in the native language of the target market, not calque-translated
- Meta tags unique per version and language
- CTAs adapted to the cultural norms of each market
- Native editorial review completed
- Canonical on every version points to itself
Technical performance
- CDN connected with PoPs in target countries
- TTFB tested from each target country (PageSpeed Insights supports location selection)
- Core Web Vitals meet thresholds in every targeted region
IP geolocation
- Googlebot is not blocked by IP-based redirects
- Language preference stored in a cookie
- All versions accessible at their direct URLs without redirection
FAQ
Which is better for international SEO — ccTLD, subdomain, or subfolder?
Subfolders are easiest to implement and accumulate the main domain's authority. ccTLDs give the strongest geo-signal but require separate link building for each domain. Subdomains sit in the middle. For most projects with limited budgets, subfolders are the most practical starting point.
Is hreflang mandatory for an international website?
It is critical whenever you have similar content targeting different languages or regions. Without it, Google may serve the wrong language version or treat pages as duplicates. That said, hreflang is just one of several signals — GSC geotargeting, localised content, and URL structure all contribute.
How do you set up geotargeting in Google Search Console?
Add each version as a separate GSC property using URL-prefix type. Then navigate to Legacy tools → International Targeting → Country and select your target. ccTLDs do not need this — Google reads the country from the TLD automatically.
What is the difference between localisation and translation?
Translation converts text between languages. Localisation adapts the entire user experience for a market — native keywords, currency, examples, and CTAs. SEO demands localisation because it matches actual search behaviour in the target country, not calque phrasing from the source language.
Expanding into new markets? Let's build your international SEO properly.
Hreflang audits, geotargeting setup, content localisation, and a full technical launch checklist — from the SEO-Factory team.
Get a promotion plan
