International SEO Strategy: What Google Actually Reads, and Four Things It Ignores

What is an international SEO strategy?

An international SEO strategy is the set of decisions made before any hreflang tag is written: which markets you are targeting, whether you are targeting languages or countries, what URL structure carries that targeting, and how you handle the same language across several regions. Google’s own documentation separates the two problems — multilingual and multi-regional are different problems — and a site can be both at once.

This article is the layer above hreflang. The site already has three articles on hreflang mechanics: implementation for multilingual SaaS, how hreflang and canonical tags reconcile, and declaring hreflang in XML sitemaps. None of that is repeated here. What is here is the strategy those tags express, and — more usefully — what Google’s documentation actually says it reads, which in four specific places contradicts what most international SEO advice recommends.

Everything below is scoped to Google. Bing, Yandex, Baidu and Naver publish their own guidance and this article does not speak for them.

TL;DR — Key takeaways

• Google determines page language from visible content. It states it does not use the lang attribute or the URL for this.
• Googlebot sends no Accept-Language header and crawls mostly from the USA. Content negotiated on either signal is effectively invisible to it.
• Google ignores geo.position and geotargeting HTML attributes outright.
• Google explicitly tells you not to adapt content by IP.
• Google treats .io, .co, .me, .ai and .tv as generic, not country-targeted. If your SaaS is on a .io, your domain carries no geographic signal.
• Automatic language redirects are advised against — they hide versions from users and crawlers.
• URL structure is the one decision that is expensive to reverse. Make it deliberately.

The four decisions that come before hreflang

1. Which markets — decided on demand, not ambition. Every locale you add multiplies content, QA, and the surface area where hreflang can break. The failure I see most often is a company that launched eight locales because the CMS made it cheap, then discovered that six of them have no local demand and no local content, and that the thin ones are dragging on crawl budget. Google is blunt about the trade: geotargeting can improve rankings in the target country at the expense of results in other locales and languages. Targeting is a choice to be less visible somewhere else.

2. Language targeting and country targeting are not the same job. A Canadian business with English and French versions is multilingual. A manufacturer shipping to both Canada and the US is multi-regional. Most SaaS companies think they are doing the second when they are doing the first — they have /de/ because they translated the site, not because they are targeting Germany specifically. That distinction determines whether you need country targeting at all, and getting it wrong produces en-GB/en-US/en-AU variants that differ by nothing but a currency symbol.

3. URL structure — the expensive one. This is the decision you cannot cheaply undo, and it gets its own section below. Everything else on this list can be changed in a sprint. Changing URL structure later is a site migration, with the risk profile of one.

4. What happens when the same language serves several regions. If example.de/ and example.com/de/ both show similar German content, you have a duplication problem that hreflang alone does not solve. Google’s instruction is to pick a preferred version and use rel=canonical together with hreflang. The mechanics of making those two tags agree are genuinely counterintuitive and are covered in hreflang and canonical tags; the decision about which version is preferred is yours, and it is the same class of judgement as canonical versus noindex.

URL structure, and the ccTLD trap most SaaS domains fall into

Google documents four URL-structure options with their trade-offs stated plainly:

Structure	Example	Google’s stated position
Country-specific domain	example.de	Clear geotargeting, server location irrelevant, easy separation — but expensive, more infrastructure, sometimes strict ccTLD eligibility rules, and it can only target one country
Subdomain on a gTLD	de.example.com	Easy to set up, allows different server locations — but users may not know whether “de” means the language or the country
Subdirectory on a gTLD	example.com/de/	Easy to set up, low maintenance — but single server location and harder site separation
URL parameters	site.com?loc=de	Not recommended

A ccTLD gives you clear geotargeting, at a cost — and the cost includes the fact that it can only ever target one country. A subdirectory concentrates authority on one domain and is the default I recommend for most SaaS companies, precisely because it is reversible and cheap to operate.

Now the part that catches people.

Google treats a list of country-code domains as generic. It treats .eu and .asia as generic despite their obvious regional association. And beyond those, it publishes a list of ccTLDs Google treats as generic because users and site owners read them as generic rather than country-targeted. That list includes .io, .co, .me, .ai, .tv, .cc, .fm, .la and .ws, among others.

Read that against how tech companies actually pick domains. A very large share of SaaS runs on .io, .co or .ai. If you are on one of those, your domain contributes no geographic signal at all — you have a gTLD, and you need to set country targeting explicitly through the other documented methods. Conversely, if someone has sold you a .io on the basis that it targets the British Indian Ocean Territory, or a .ai for Anguilla, Google’s documentation says otherwise.

Google does note the list may change, so it is worth re-reading before you commit a domain strategy to it. But the direction of travel is clear, and the practical rule holds: check your TLD against that list before assuming it does any geographic work. Most of the SaaS audience this affects has never looked.

What Google actually reads — and four things it ignores

This is the section that justifies the article. Each of these is stated in Google’s documentation and each contradicts something widely recommended.

Google does not use the lang attribute to determine page language. It uses the visible content, and says so directly: it does not use code-level language information such as lang attributes, or the URL. Set lang anyway — it matters for accessibility and for screen readers, which is reason enough — but do not expect it to tell Google what language a page is in. A page whose lang="de" sits above English content is an English page as far as Google is concerned.

To be precise about the boundary: this is about language determination. It is not a statement about hreflang, which is an explicit annotation Google does read and act on. The two are separate mechanisms and it is worth not conflating them.

Googlebot sends no Accept-Language header. Google states that the crawler sends HTTP requests without setting Accept-Language, and that it usually originates from the USA. If your server picks a language from that header, Googlebot receives whatever your default is — every time, for every locale. Your other language versions are not being ranked badly; they are not being seen. That is also why log-file analysis is the fastest way to find out which locales Googlebot is actually fetching, rather than which ones you believe you published.

Google ignores locational meta tags. geo.position, distribution and geotargeting HTML attributes are ignored. They still appear in CMS templates and in international SEO checklists. They do nothing.

Do not adapt content by IP. Google’s instruction is direct — don’t use IP analysis to adapt your content — on the grounds that IP location analysis is unreliable and that Google does not vary its crawl location to detect variations. A US-origin crawler hitting an IP-adapted site sees the US version of everything, permanently.

So what does count? Google lists the signals it says it does use: ccTLDs, hreflang statements in tags, headers or sitemaps, server location, and a category of “other signals” — local addresses and phone numbers on the page, local language and currency, and links from other local sites.

That last group is the one most technical teams under-invest in, because it is not a tag. A German page with a German address, a German phone number, prices in euros, and inbound links from German sites is doing more geographic signalling than any meta tag ever could.

Stop redirecting people by language

Auto-redirecting a visitor to “their” language version is close to universal, and Google advises against it. The documentation says to avoid automatically redirecting users from one language version to another, because those redirections can prevent users and search engines from viewing all the versions of your site. The recommended alternative is unglamorous: put visible links to the other language versions on the page and let people choose.

Combine that with the two facts above and the failure compounds. A crawler arriving from the USA, sending no Accept-Language header, hitting a site that redirects by inferred language, gets sent to the US or English version of every URL it tries. Your other locales exist, are linked, are in your sitemap — and are never fetched. They then sit in the state described in crawled, currently not indexed, or never get crawled at all, and the diagnosis looks like a content-quality problem when it is a redirect rule.

If you must detect and suggest, suggest. A dismissible banner offering the German version is fine. A 302 that takes the decision away from both the user and the crawler is not.

The checklist

Ordered by how expensive each item is to reverse, because that is the order in which they should be decided.

1. Confirm the market list against demand, not against what the CMS supports. Every locale you keep must have someone who wants it and content worth serving them.
2. Decide language targeting or country targeting per market. Write it down. If two locales differ only by currency symbol, you have one locale and a pricing component.
3. Choose the URL structure deliberately, using Google’s stated trade-offs. Subdirectory unless you have a specific reason. Never URL parameters.
4. Check your TLD against Google’s generic-ccTLD list. If you are on .io, .co, .ai or .me, plan for zero geographic signal from the domain.
5. Remove IP-based content adaptation and automatic language redirects. Replace with visible language links.
6. Stop relying on Accept-Language. Every locale needs its own URL.
7. Delete geo.position and friends from the templates. They do nothing and they imply a strategy nobody is running.
8. Set the same-language duplication policy — preferred version, rel=canonical, hreflang agreeing with it.
9. Then implement hreflang, using the three articles linked above.
10. Verify rather than assume. Check which locale URLs Googlebot actually fetches in your logs, and which ones are indexed. This belongs in the recurring technical SEO audit cadence rather than being a launch-day task.

Items 1 through 4 are strategy. Items 5 through 7 are usually deletions — most international SEO work on an existing site is removing things that are actively preventing Google from seeing what you published.

Frequently asked questions

Should I use a ccTLD or a subfolder?

Google documents trade-offs rather than a preference. A ccTLD gives clear geotargeting but is expensive, needs more infrastructure, and can target only one country. A subdirectory is cheap, low-maintenance and keeps authority on one domain, at the cost of a single server location and harder separation. For most SaaS companies a subdirectory is the better default, largely because it is reversible.

Does a .io domain help me rank in a specific country?

No. Google publishes a list of country-code domains it treats as generic, and .io is on it — along with .co, .me, .ai and .tv. If your domain is one of those, it carries no country signal and you need to set targeting explicitly by other means.

Does the lang attribute tell Google what language my page is in?

No. Google states it determines page language from the visible content and does not use code-level information such as lang attributes or the URL. Keep lang for accessibility, but it is not a language signal to Google. This is separate from hreflang, which Google does read.

Should I redirect visitors to their local version based on IP?

Google advises against both IP-based content adaptation and automatic language redirection. IP location analysis is unreliable, and Google does not vary its crawl location, so a US-origin crawler will simply be served the same version of every page. Offer a visible choice instead.

Do I need hreflang if I have one language across several countries?

That is exactly the case hreflang is designed for — distinguishing en-GB from en-US from en-AU. But first check whether those versions genuinely differ. If the only difference is a currency symbol, you may be better served by one page and a localised pricing component than by three near-duplicate URLs.

Does server location still matter?

Google lists it among the signals it uses, while noting it is not definitive since sites commonly use CDNs or host where the infrastructure is better. Treat it as a weak signal you should not architect around.

How do I know which locale Google is actually indexing?

Check your server logs to see which locale URLs Googlebot fetches and how often, then check indexing status for a representative URL per locale. Those two together tell you whether a locale is being ignored at the crawl stage or the index stage, which are different problems with different fixes.