Search Console has no language dimension, so on a site in more than one language you separate the data by page or by country and nothing else. That single fact decides most of what follows: the URL structure you chose for translations is also the reporting structure, and a site whose German pages are not distinguishable by their address cannot be measured in German at all. One property covers every language on a host; the split has to come from the URLs.
The seven dimensions are query, page, country, device, search appearance, date and hour. Country is the closest thing to a language proxy and it is not one: a German speaker in Switzerland and a French speaker in Switzerland both report as Switzerland, and a Spanish page can earn most of its clicks from a country whose main language is not Spanish. Country tells you where the searcher was, and language tells you what they read, and search reporting only carries the first of the two.
There are three usual ways to give a site more than one language, and each one produces a different Search Console setup. What matters for reporting is whether the language is visible in the address, because the page dimension is where a language has to be recovered from.
| How the translations are addressed | What you set up in Search Console | How you separate the languages |
|---|---|---|
| Subdirectories, such as /de/ and /fr/ | One property for the whole site | Filter the page dimension by the path segment, one request per language |
| Subdomains, such as de.example.com | A domain property covers them all; URL-prefix properties are one per subdomain | Filter by page, or read each subdomain's property on its own |
| Country domains, such as example.de | A separate property per domain, because they are separate sites | Read each property separately; there is no combined view to filter |
| One address that serves different languages to different readers | One property, and no way to tell the versions apart | Not separable, which is a strong argument against this arrangement |
Filtering by page is where people hit the wall that Search Console's query interface imposes: filters have no OR. Every filter and every grouping is combined with AND, so a report for German and French together is two requests whose results you merge yourself. Plan the reporting as one pull per language rather than one clever pull that covers all of them.
A report that arrives every Monday whether or not anything happened teaches its reader to ignore it. Three constraints fix that: alert only above a severity floor, only on kinds worth interrupting somebody for, and only when the finding is new.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
A page's language and its translations are two different pieces of information, and they are often confused. The language tag on a page says what this page is written in. The hreflang annotation says that this page and that page are translations of each other, which is a relationship between pages rather than a property of one. A page has to be able to state its own language before the second sentence means anything at all.
Market4 stores a content language per app, per blog post, per changelog entry and per brand kit, and it deliberately does not emit hreflang from that field. Declaring that two pages are translations of one another is a relationship, and no such relationship is stored; generating hreflang out of a lone language tag would be inventing it. What the stored language does control is the lang and dir attributes on the rendered page, the language of e-mail templates, the locale a rank check is run in, and whether the readability check runs at all.
Readability scoring in Market4 is English only, and it says so rather than scoring anything else wrongly. Flesch-Kincaid and its relatives count English syllables and English sentence patterns; run on Turkish or German they still return a number, and the number means nothing. A score that is confidently wrong is worse than a refusal, so a non-English draft comes back with applicable false and a reason naming the language it detected and where that language came from.
The same caution applies to rank checking on a multilingual site. A tracked keyword's identity includes its country and its language, so the same words tracked for another locale are a separate record on purpose. A rank check run in the wrong language is a measurement of somebody else's results page, and it will look like a perfectly ordinary position number.
Only if the languages live on separate domains. Subdirectories all sit in one property and are separated by filtering the page dimension. Subdomains are covered together by a domain property, or individually by one URL-prefix property each. Country domains are genuinely separate sites and need a property each, with no combined view; that is the trade you accept when you choose that structure.
No. The performance report groups by query, page, country, device, search appearance, date and hour, and language is not among them. You recover language from the page dimension when the address contains it, which is why a URL structure that hides the language also hides it from every report. Country is not a substitute, because several languages are searched from the same country.
It changes which version of a page Google serves to which searcher, so it moves impressions and clicks between your pages. It does not add a language dimension to the report or group anything for you. Read the effect of hreflang as a redistribution across pages in your existing report: the same total demand landing on different addresses than before.
It makes the page hard to index and impossible to report on. Google sees one address, so the two versions share one row in every report and you cannot tell which one earned anything. A distinct address per language is what makes the content indexable separately, linkable separately, and measurable at all, and it is the arrangement everything else in international search assumes.
Search Console's regex filters are RE2 expressions, which is a deliberately smaller syntax than the one most regex tutorials teach. What RE2 leaves out, what to write in place of each missing construct, and the two things a filter does not change.
Search Console will group performance rows by seven dimensions, and searchAppearance is the one that says which result feature an impression came from. It also changes how the totals are aggregated, which is the part that surprises people.
