International SEO audit, what to check and in what order

An international SEO audit checks whether search engines can tell your market versions apart, and whether they are sending each visitor to the right one. Three things decide that. The URL structure your versions sit on, the hreflang annotations that connect them, and the duplication you create when two versions speak the same language. Almost every failure in this area is one of those three, and all three are checkable.

The reason it goes wrong quietly is that nothing breaks. Every version returns a 200, every page looks right in a browser, and the only symptom is that the wrong version ranks in the wrong place, or one version disappears. This walks through what to check, in the order that stops you fixing symptoms, and every rule below is quoted from Google’s own documentation rather than a summary of it. If you want the general procedure first, our guide to running a full SEO audit covers the ground that is not market specific.

What an international SEO audit actually checks

An international SEO audit is a normal technical audit plus one extra question asked of every page, which is whether this page is the right one for the person seeing it. That question has no equivalent on a single market site, and it is the reason the work is different rather than just larger.

Start by writing down what you actually run, because most teams are less sure than they expect. For every version you publish, record the language, the market it is meant for, the URL pattern it lives on, and who maintains it. A version nobody has updated in two years is a finding before you look at a single tag.

Then separate the two things that get merged. Language targeting is about what a page is written in. Market targeting is about who it is for. They are not the same and they do not always move together. One language can serve many markets, one market can contain several languages, and the version that sells in one place may be written in the same language as a version that sells somewhere else entirely.

Worth knowing before you begin, because it changes what the tags are for. Google’s documentation states plainly that it “doesn’t use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language” (developers.google.com/search/docs/specialty/international/localized-versions, read 16 September 2026). Hreflang does not tell Google what language a page is in. It tells Google which other pages are alternates of it. That distinction explains most of the confusion in this subject.

Which URL structure your versions sit on, and what it costs you

The structure was usually chosen years ago by whoever built the site, and it sets the ceiling on everything else. Google documents four options with its own pros and cons for each, and the table below is drawn from that page.

All quotations above are from developers.google.com/search/docs/specialty/international/managing-multi-regional-sites, read 16 September 2026.

The audit question is not which structure is best. It is whether the one you have matches what you are trying to do. Elsewhere on the same page Google explains why the country-code domain is the strongest of the four, that these are tied to a specific country and “therefore provide a strong signal to both users and search engines that your site is explicitly intended for a certain country”. It also locks you to one country, which is a poor trade if your real split is by language rather than by border. A subdirectory is cheap to run and inherits the authority of the main domain, which is usually the right answer for a site whose markets are not separate businesses.

Two things make this expensive to get wrong. Changing structure later means migrating every URL, and mixing structures means you are maintaining two sets of rules at once. If your audit finds a country domain for one market and a subdirectory for another, that is not automatically broken, but it is the thing to understand first, because every later finding will trace back to it.

How hreflang works, in Google’s own words

Hreflang is the annotation that tells a search engine a set of pages are alternate versions of each other. Get it right and the engine can swap in the version that fits the visitor. Get it wrong and the annotations are ignored, which puts you back where you started without telling you.

The value itself has a defined shape. Google specifies that the first code is “the language code (in ISO 639-1 format) followed by an optional second code that represents the region code (in ISO 3166-1 Alpha 2 format) of an alternate URL”, giving en-US as its example, and states that “Only language codes listed in ISO 639-1 and region codes listed in ISO 3166-1 Alpha 2 are supported”. The region half is optional. The language half is not.

Three rules govern every implementation, all quoted from the same page.

• Every version lists every version, itself included. Google’s wording is that “Each language version must list itself as well as all other language versions.” A page that lists its alternates but omits itself is a common and silent fault.
• The links go both ways. “If page X links to page Y, page Y must link back to page X. If this is not the case for all pages that use hreflang annotations, those annotations may be ignored or not interpreted correctly.”
• The URLs are absolute. “Alternate URLs must be fully-qualified, including the transport method (http/https)”, so a protocol-relative or root-relative path does not qualify.

There is also a fallback worth checking for, because most sites skip it. The x-default value marks the page to use when no listed version matches the visitor, and Google suggests it “especially on language/country selectors or auto-redirecting home pages”. If you have a selector page, that is what it is for.

One piece of relief in the documentation, which contradicts how strictly this is usually taught. Google says that “If it becomes difficult to maintain a complete set of bidirectional links for every language, you can omit some languages on some pages; Google will still process the ones that point to each other.” It attaches a condition in the next breath, that it “is important to link newly expanded language pages bidirectionally to the originating/dominant language(s)”, so the links you drop are the peripheral ones and never the link back to your strongest version. A partial set that is internally consistent still works. A complete set that disagrees with itself does not.

The hreflang mistakes that make Google ignore your tags

Google publishes its own list of the most common hreflang mistakes, which is the closest thing this subject has to a graded exam. Check yours against it directly rather than against a tool’s opinion.

• Missing return links. The bidirectional rule above, and the single most common failure. It usually appears when one market is managed by a different team or on a different platform, so its pages never learned about the others.
• Incorrect language codes. Google’s instruction is to make sure codes identify the language in ISO 639-1 and optionally the region in ISO 3166-1 Alpha 2, and it states outright that “Specifying the region alone is not valid.” A value naming only a country, with no language in front of it, is not a valid annotation.
• Incorrect region codes. Google asks you to “make sure you’re using officially assigned code elements for the regions you’re trying to identify”, which rules out invented or informal abbreviations however obvious they look.
• Annotations that point at dead or redirected URLs. This fourth one is ours, not Google’s. Google’s published list stops at the three above. We add it because it follows from the return link rule, since a page that has moved or gone cannot link back, so treat it as a consequence of documented behavior rather than as documentation.

The reason these matter more than they look is the consequence. The penalty for a broken annotation is not a warning or a ranking drop. Google’s wording is that the annotations “may be ignored or not interpreted correctly”, which means the site behaves exactly as if you had never implemented hreflang at all, while the tags sit in the source looking correct to anyone who glances at them.

So audit the annotations by crawling them, not by viewing source on a few pages. You are checking a graph, and a graph is only sound if every edge points both ways. Several crawlers will map that graph for you, and our comparison of free SEO tools covers which of them will do it without a subscription.

Why two versions in the same language compete with each other

This is the finding teams are least prepared for, because nothing about it looks like an error. You publish one version for one market and another for a second market, both in the same language, and the pages are necessarily similar. Now you have two near identical documents competing for the same queries, and the engine has to pick.

Google addresses this case directly. Its guidance is that if you provide “similar or duplicate content on different URLs in the same language as part of a multi-regional site”, you should “pick a preferred version” and use the canonical element together with hreflang tags, and it gives the example of two versions both showing similar content in one language. Canonical and hreflang are doing different jobs here and both are needed.

The practical test is blunt. Take a page from each same-language version and compare them properly. If the only differences are a currency symbol, a phone number and a spelling variant, you have one page published twice and you should expect the engine to treat it that way. If the products, the prices, the terms and the examples genuinely differ, they are different pages and the annotations should be enough.

What this means for the audit is that some findings are not technical at all. A same-language duplication problem is usually solved by writing rather than by tagging, or by deciding that one of the two versions should not exist. That is a harder conversation than fixing a tag and it is more often the right answer. Where the two versions are storefronts with different catalogs, the shape of the problem changes again, and our walkthrough of an ecommerce site audit covers the catalog side of it.

What country targeting can and cannot do for you

Beyond URL structure and annotations there is explicit targeting, and it is worth understanding what you are buying with it. Google’s description is that you “can target your website or parts of it to users in a single specific country that speaks a specific language”, and then states the cost in the next breath, that this “can improve your page rankings in the target country, but at the expense of results in other locales or languages”.

Read that as the trade it is. Targeting is not a free improvement, it is a decision to be more findable in one place and less findable everywhere else. For a business whose customers are genuinely in one place that is obviously correct. For a business selling to anyone who speaks a language, it is a way to lose the rest of them.

Two limits are worth knowing before you rely on it. Google’s documentation states that it “ignores locational meta tags (like geo.position or distribution) or geotargeting HTML attributes”, so markup claiming a location is not a signal. And a country-code domain already carries the targeting on its own, which is why Google lists “Can only target a single country” as a cost of that structure rather than a feature.

The audit action is to list every place a targeting decision has been made, including ones nobody remembers making, then check each against who actually buys from you. Server location, domain choice, explicit settings and any redirect logic all count. Where those disagree with each other, the engine is receiving mixed instructions and so is the visitor.

How to tell a translation problem from a targeting problem

When a version underperforms, the cause is either that the right people cannot find it or that they find it and it does not speak to them. Those need opposite fixes and they are routinely confused, so separate them before spending anything.

A targeting problem shows up as absence. The version is indexed, technically fine, and receives almost nothing from the market it was built for, while another version of your own site ranks there instead. That is a structure and annotation question and the earlier sections cover it.

A translation problem shows up as arrival without result. The version ranks, it gets visitors from the right market, and they leave. The usual cause is that the page was translated rather than rewritten, so it now says in one language what buyers in that market do not search for. The phrase people type for a product is frequently not the dictionary translation of the phrase used elsewhere, and no amount of correct tagging fixes a page built on the wrong phrase.

The check that separates them is to look at what each version is found for rather than how much it is found. If the queries arriving are the translated versions of your existing terms and the volumes are tiny, the keyword research was done once and translated, which is a content finding. Our explanation of SEO visibility covers reading that pattern, and because positions vary by where a search happens, our explanation of SEO ranking is worth reading before you compare two markets’ numbers at all.

What to check in Search Console before changing anything

Every finding above should be confirmed against what the engine actually did before you act on it. Search Console is free, it is first party, and it is the only source in this article reporting behavior rather than configuration.

Four checks are worth the time, in this order.

• Is each version indexed at all. Run the page indexing report per version. A version that is not indexed cannot be targeted, and every other finding on it is irrelevant until that is fixed.
• Which version is receiving which market. Break performance down by country and compare it against what each version was built for. Mismatches here are the symptom the whole audit exists to explain.
• Whether one version is absorbing the others. If a single version takes traffic from everywhere, your annotations are probably being ignored and the engine has picked a favorite.
• Whether the queries match the language. Queries arriving in one language on a version written in another tell you the targeting and the content disagree.

Verify coverage per version rather than for the site as a whole. A property covering everything averages your markets together and hides exactly the problem you are looking for, which is one version doing badly while the total looks acceptable.

The audit in order, and what to fix first

Order matters here more than in a single market audit, because several of these findings cause each other. Working the list in the wrong sequence means fixing symptoms and watching them return.

Notice that the cheap fixes sit near the top and the expensive one sits at the bottom. That is not a coincidence, it is the order dependency doing the sorting for you. It also means an audit that opens with a recommendation to rewrite every version has skipped the six checks that would have told it whether rewriting was the problem. For what a finished report should contain regardless of subject, our breakdown of an SEO report sets the bar, and our guide to conducting a website audit covers the checks that are not market specific.

What we would do first, and what to ask us

With a multi-version site and one day, we would not start with the tags. We would build the inventory first, every version listed with its language, its intended market, its URL pattern and its owner, because in our experience that document does not exist and producing it surfaces two or three findings on its own. Versions nobody owns are usually the ones failing.

Then we would crawl the annotation graph rather than inspect pages, confirm indexation per version in Search Console, and only then read the tags in detail. That order exists because a broken return link makes every targeting observation meaningless, so checking targeting first wastes the day.

Now point it at us, because we sell audits and this article is an argument for buying one. The test it sets is that findings are quoted to a published source and ordered by dependency rather than by severity. Ask us which of your versions is not indexed, which return links are missing, and why a finding sits where it does in the list. An audit that hands you a severity-sorted export has answered a different question, and that applies to ours as much as to anybody’s. If you want to see who does this kind of work and how they differ, our explanation of what search engine optimization companies do is the wider view.

So the first move costs nothing. Write the inventory, open the page indexing report for each version, and see whether the engine has stored what you think it has. If you would rather have the findings handed to you, our free website audit is where to start.