International SEO is the practice of structuring, targeting and signaling a website so the right country and language version ranks for the right audience in each market. It rests on three decisions: a URL structure (ccTLD, subdomain or subdirectory), correct hreflang annotations that tell search engines which pages are equivalent, and market-specific research and content rather than one site translated everywhere. Get the URL structure or hreflang wrong and search engines will show visitors the wrong country's page, split your ranking signals across near-duplicate content, or ignore your regional targeting entirely.
What Is International SEO, and Where Do You Start?
International SEO differs from standard SEO in one respect: you are optimizing for multiple markets at once, each with its own search behavior, competitors and sometimes its own language. The starting point is not translation, it is market selection. Rank each candidate market by search demand for your product category, competitive intensity and commercial upside, using a keyword research tool alongside your own sales and support data.
Keyword research does not transfer across languages. A term that converts well in English often has no direct equivalent, a different search volume, or a completely different phrasing in German or Hebrew. Treat each target market as its own keyword research project, run in the local language by someone who understands both the language and the product. Where Hebrew and English queries mix in the same search session, our guide to Hebrew and bilingual SEO in Israel covers that added wrinkle in detail.
ccTLD vs Subdomain vs Subdirectory: Choosing Your URL Structure
Your URL structure is the foundation every other international SEO decision sits on, and it is expensive to change later. Google's own guidance on managing multi-regional and multilingual sites treats ccTLDs, gTLD subdomains and gTLD subdirectories as valid options, each with different trade-offs, and explicitly advises against using URL parameters for market targeting.
| Structure | Example | Geotargeting signal | Setup and maintenance | Best fit | | --- | --- | --- | --- | --- | | ccTLD | example.de | Strongest explicit signal to users and search engines | Highest: a separate domain, hosting and sometimes a local entity per market | Large multi-country businesses with a market-specific brand or legal need | | Subdomain | de.example.com | Moderate; can point to a different server location per market | Moderate: a distinct section that is easy to spin up | Larger organizations splitting infrastructure or teams by market | | Subdirectory | example.com/de/ | Moderate; relies on hreflang and content, not the URL alone | Lowest: one domain, one hosting setup, shared authority | Most companies expanding abroad, especially smaller teams | | URL parameters | example.com?loc=de | Weak; Google does not recommend this pattern for targeting | Low setup, but poor separation of content and tracking | Not recommended as a primary market-targeting structure |
For most companies expanding from a single home market, a subdirectory is the pragmatic choice. It keeps every market on one domain, so backlinks and domain-level trust accumulate in one place instead of splitting across separate properties that each have to earn authority from zero.
Illustrative scenario: an Israeli SaaS company with one example.com domain and an established backlink profile decides to open UK and German markets. Assumptions: a single domain with real authority, a small marketing team, and no local legal requirement for a country-specific domain. Subdirectories such as example.com/uk/ and example.com/de/ let the new market pages inherit that domain-level trust immediately, instead of starting a new ccTLD's authority from nothing.
When Does a ccTLD Still Make Sense?
A ccTLD earns its extra cost when local trust or regulation depends on it: regulated industries such as banking or insurance, government-adjacent services, or markets where a local domain measurably outperforms a foreign one in user trust. Some ccTLDs also carry registration restrictions, such as requiring a local business presence, so confirm eligibility before you commit a roadmap to one. A hybrid is common too: a ccTLD for your single most strategic market, subdirectories for the rest.
How Do You Implement Hreflang Correctly?
Hreflang is an HTML, HTTP header or sitemap annotation that tells search engines two or more pages are equivalent versions of the same content for a different language or region. It does not translate content and does not directly affect rankings; it only affects which version search engines show to which searcher. Google's documentation on localized versions of your pages sets out five rules worth treating as a checklist:
- List every version, including the page itself. Each URL's hreflang set must contain a self-referencing entry, not only links to the other versions.
- Make every relationship bidirectional. If your English page links to the German page, the German page must link back to the English page and every other version. Google states plainly that when two pages do not both point to each other, the annotations are ignored.
- Use valid codes only. Language codes must follow ISO 639-1 (for example en, de, he) and region codes must follow ISO 3166-1 Alpha-2 (for example GB, DE, IL). A region code cannot stand alone, and reserved codes such as EU, UN or UK are ignored.
- Add x-default for a market-neutral or language-selector page. This reserved value tells search engines which version to show when no other language or region matches the visitor's browser settings.
- Pick one implementation method and apply it consistently. HTML link tags, an HTTP header, or sitemap annotations all work; mixing methods across the same URL set invites errors.
Example: a site with English, British English, German and Hebrew homepages would carry this identical block of tags on all four pages, which satisfies both the self-reference and bidirectional rules at once:
<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
<link rel="alternate" hreflang="he" href="https://example.com/he/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/" />
Hreflang via HTTP Header or XML Sitemap
Non-HTML files such as PDFs cannot carry a <link> tag in a head element, so Google supports the same relationship as an HTTP header instead. Each URL in the header value is wrapped in angle brackets per the underlying web-linking standard, shown here as plain URLs for readability:
Link: example.com/en/; rel="alternate"; hreflang="en",
example.com/de/; rel="alternate"; hreflang="de",
example.com/he/; rel="alternate"; hreflang="he",
example.com/en/; rel="alternate"; hreflang="x-default"
Large sites often prefer a sitemap instead, since it keeps hundreds of annotations out of every page's head. Declare the xmlns:xhtml="http://www.w3.org/1999/xhtml" namespace on the sitemap's root element, then add one xhtml:link per alternate inside each url entry:
<url>
<loc>https://example.com/en/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/" />
<xhtml:link rel="alternate" hreflang="he" href="https://example.com/he/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/" />
</url>
Common Hreflang Mistakes to Avoid
Most hreflang failures trace back to a handful of repeat offenders. This table maps each one to why it fails and how to fix it, drawn directly from Google's own guidance.
| Mistake | Why it fails | Fix | | --- | --- | --- | | Missing return links | Google ignores the annotation on both pages when it is not bidirectional | Audit every hreflang set for full reciprocity before and after each content update | | Region code without a language | A region code used alone is not supported | Always pair a language code first and a region code second, such as en-GB | | Reserved or unsupported codes | Codes such as EU, UN, UK or es-419 are ignored or unsupported | Use only ISO 639-1 language codes and ISO 3166-1 Alpha-2 region codes | | No self-referencing tag | Search engines cannot confirm the page's own place in the set | Include the page's own URL in its own hreflang block | | Auto-redirecting by IP or Accept-Language | Traps users and crawlers on one version; Google recommends against it | Show a dismissible banner suggesting the local version instead | | Hreflang pointing to a redirect, noindex or error page | Wastes the annotation and can suppress the target page | Point only to indexable, 200-status canonical URLs |
How Do You Add Hreflang to a Next.js Site?
Next.js's metadata API generates correct, self-referencing hreflang tags from a single object, which removes most of the manual bookkeeping that causes the mistakes above. In generateMetadata, the alternates.languages field accepts a map of language codes to URLs, including x-default:
import type { Metadata } from "next";
export async function generateMetadata({
params,
}: {
params: { locale: string };
}): Promise<Metadata> {
return {
alternates: {
canonical: `https://example.com/${params.locale}/`,
languages: {
en: "https://example.com/en/",
"en-GB": "https://example.com/en-gb/",
de: "https://example.com/de/",
he: "https://example.com/he/",
"x-default": "https://example.com/en/",
},
},
};
}
The sitemap.ts file convention supports the same pattern per URL, and Next.js renders it as the xhtml:link structure shown earlier, automatically:
import type { MetadataRoute } from "next";
export default function sitemap(): MetadataRoute.Sitemap {
return [
{
url: "https://example.com/en/",
lastModified: new Date(),
alternates: {
languages: {
de: "https://example.com/de/",
he: "https://example.com/he/",
},
},
},
];
}
Generating both from the same locale configuration, rather than hand-writing tags per page, is what keeps large sites' hreflang sets bidirectional as pages are added, renamed or removed. For the wider rendering and indexing picture on React and Next.js, see our JavaScript SEO guide for React and Next.js.
Localization vs Translation: What Actually Changes Per Market
Translation changes the words. Localization changes the product experience: currency and pricing display, units of measurement, date formats, legal disclaimers, payment methods, imagery, case studies and even tone. A German enterprise buyer and a US startup founder respond to different proof points on the same landing page, even when both read English. Treating localization as "translate the English page" is the single most common reason international pages underperform their home-market equivalent.
Content depth matters as much as accuracy. A market page that is a thin, literal translation of the home page, with no local examples, currency or context, tends to convert worse and can read as low-value, duplicate-adjacent content to both visitors and search engines. Budget for a local editor or reviewer in every market you take seriously, not only a translation pass. Our website migration SEO checklist covers the related risk of losing signals when you restructure URLs to support new markets.
Why Geo-Redirects Hurt International SEO (and What to Do Instead)
Automatically redirecting visitors to a different language or country version based on their IP address or browser language feels helpful, and it is one of the most common ways sites damage their own international SEO. Google's guidance is direct: "Avoid automatically redirecting users from one language version of a site to a different language version," because it can prevent both users and search engines from viewing all the versions of a site. Google also warns that IP-based content adaptation is unreliable on its own, stating that "IP location analysis is difficult and generally not reliable."
The practical failure mode is crawling, not just user experience. A crawler that always gets redirected to one country's version from every URL it tries can end up never reaching, and never indexing, your other market pages at all. Google's recommended alternative is simpler and safer: show a dismissible banner suggesting the local version, and add visible hyperlinks so users can choose a different language or region themselves. Keep the requested URL reachable either way.
How Do You Launch a New Market and Measure It?
Local link building and digital PR matter more once your technical foundation is correct, because a page that ranks in principle still needs local authority to rank in practice. Pursue links and mentions from publications, directories and partners inside each target market rather than relying only on links pointed at your home-market domain. Measurement changed in 2022, when Google removed Search Console's International Targeting report, which had been the main place to see hreflang errors and set a country target; Google confirmed it would keep processing hreflang tags even without that report. Most teams now validate hreflang with a site crawler or script before launch and lean on the Performance report, filtered by country and page, to confirm the right version is ranking in each market.
International Market Launch Checklist
- Rank candidate markets by demand, competition and commercial upside before writing a line of content.
- Choose a URL structure (ccTLD, subdomain or subdirectory) that fits your team's resources and any local legal requirements.
- Commission local-language keyword research for each market; never machine-translate a keyword list.
- Build hreflang annotations for every URL set: self-referencing, bidirectional, valid ISO codes, and x-default where relevant.
- Choose one hreflang implementation method (HTML, header or sitemap) and apply it consistently across the market.
- Localize content beyond translation: currency, units, legal disclaimers, imagery, payment methods and examples.
- Confirm there are no automatic geo-redirects; add a dismissible language or region suggestion banner instead.
- Validate hreflang reciprocity and codes with a crawler or script before launch, since Search Console no longer has a dedicated report for it.
- Set up per-market tracking filtered by country and query, then invest in local links and PR in each market.
How Agentixly Approaches International SEO
Agentixly treats a new market as a scoped program, not a translation task bolted onto an existing site. A typical engagement starts with market prioritization against your actual sales data, then an architecture decision (ccTLD, subdomain or subdirectory) made with your engineering team, because that choice has to work inside your existing Next.js or other framework setup, not around it.
From there, Agentixly's SEO team implements hreflang as code, generated from a single locale configuration rather than hand-maintained per page, and pairs it with local-language keyword research and content review for each market. Because web development, SEO and GEO sit inside one team, the same engineers who ship your hreflang and redirect logic also own the site's rendering and performance, so nothing gets lost in a handoff between an agency's recommendation and your developers' backlog.
Next Steps
International SEO succeeds or fails on details: a URL structure your team can maintain, hreflang sets that are self-referencing and fully reciprocal, and content localized market by market instead of translated once and forgotten. Start with the market launch checklist above, validate your current hreflang setup for the mistakes in this guide, and treat every new market as its own small program with its own keyword research and links.
If you are planning a multi-market expansion and want the URL architecture, hreflang and local content strategy built correctly the first time, explore Agentixly's SEO services or tell us about your markets. We answer every inquiry within 24 hours.