Reading Search Console when your team is English and your market is German

Berlin SEO editorial team21 August 2026updated 31 August 2026

Your product is in English, your support is in English, your standups are in English. Your Search Console report is not. Roughly half the queries bringing people to your site are German, written by people who will never read a word of your interface copy — and nobody on the team can tell whether those queries represent buyers or noise.

This is the standard situation for a company built in Berlin by people who arrived from somewhere else. It is not a translation problem and it is not a marketing problem. It is a measurement problem: the report is telling you something specific, in a language the people reading the report do not operate in, and so the information sits there unused for months.

The report already knows more than the team does

Search Console records what people typed, how often it produced an impression, how often that turned into a click, and roughly where you sat in the results. Four columns, nothing more. In a single-language company those four columns are read once a week and forgotten. In a company where the audience and the operators speak different languages, they are the only honest description of who is actually looking for you.

The fourth row is where most misreadings begin. An average position of nine can mean you sat at nine every single time, or that you sat at three for a handful of queries and at twenty for everything else. Those are two entirely different situations calling for two entirely different responses, and the column presents them identically.

There is a second, quieter problem with averages in a bilingual property. The mean is calculated across every impression regardless of query language, so a page performing well for its English audience and badly for the German queries it accidentally attracts reports as mediocre for both. Nothing in the interface flags this. The page looks like an ordinary underperformer, gets rewritten, and comes back with the same number — because the number was never describing one thing in the first place.

Split by query language before anything else

Most teams segment by page or by device. In a company whose site is English and whose market is partly German, both of those are the wrong first cut. The useful split is by the language of the query, because it separates two audiences with different intent, different competition and different conversion behaviour that otherwise average into one meaningless number.

Once those two segments sit side by side, a question that previously had no answer becomes answerable: is the German demand large enough to justify German pages? Not as a matter of principle, but as a matter of counted impressions. In many cases the answer is a clear yes for two or three specific topics and a clear no for everything else — which is a far more useful conclusion than a decision to translate the whole site.

Doing this split by hand is tedious but not difficult: German queries are recognisable at a glance, and a couple of hundred rows can be sorted in twenty minutes the first time. What matters is that it is done once properly and then kept, rather than re-derived from memory whenever someone asks. Once the segments exist as a saved filter, every subsequent question inherits them for free, and the weekly review stops starting from zero.

One caution worth stating plainly: the split is by query language, not by page language. A German query can perfectly well land on an English page, and that combination is exactly the case worth isolating. Teams that instead segment by URL prefix end up measuring their own site structure rather than their audience, which feels rigorous and answers nothing.

Neither column means anything alone

Both patterns are invisible in a summary view. They only appear when position and rate are read as a pair, which is why a dashboard showing total clicks over time — the default in most reporting setups — provides almost no operational information at all. It tells you whether things are broadly getting better. It never tells you what to do on Tuesday.

A third pattern deserves mention because it is specific to companies in this position: strong position, strong rate, no revenue. German queries that convert well into visits and never into enquiries usually indicate that the visitor found what they were looking for informationally and hit a wall at the point of contact — a form in English, a pricing page assuming a different market, a support promise that does not extend to their language. The report ends at the click, so this failure is invisible in it entirely and only surfaces when someone compares the two segments downstream.

Search Console and rank tracking answer different questions

For a bilingual company the first row matters most. Search Console can only report German queries you already appear for. Queries where you are absent entirely — because no page addresses them — leave no trace at all. That blind spot is precisely where the untapped German demand sits, and closing it requires a deliberately chosen watch list rather than a report of what already happened. Keeping both views in one workspace removes the reconciliation step that otherwise consumes an afternoon each month.

A practical consequence for the watch list: it should contain German queries you do not yet rank for at all. That feels wrong at first, because the list stays empty for weeks. But an empty row is information — it says the gap is still open — whereas a list containing only queries you already appear for can never tell you anything you did not already know.

The queries that never become clicks

A growing share of searches now end inside a generated answer. The user reads a synthesised paragraph, gets what they needed and never visits a result. In Search Console this shows up as impressions without clicks, and it is indistinguishable from a page that simply performed badly — which means the standard interpretation is wrong for a growing slice of the report.

This matters twice over in a bilingual setting, because generated answers are produced independently per language. Being cited in English answers tells you nothing about whether you are cited in German ones, and the two often diverge sharply — an English-language source with strong technical documentation can be well represented in one and entirely absent from the other. Checking both requires asking the same question twice, once in each language, and recording the answer. Tracking that in a single place alongside the conventional numbers is what keeps the comparison honest over time.

The practical instruction is short. Once a month, ask three or four questions that matter to your business in both languages, note whether a generated answer appears, and note whether you are mentioned in it. Ten minutes of work, recorded consistently, produces a trend line within a quarter — and that trend line is the only evidence available on this question, since no report exposes it directly.

Three audiences, three formats

The most common mistake in a small team is using one export for all four. A ten-thousand-row table in a board pack looks thorough and goes unread; a summarised view in the weekly meeting generates questions that the detailed view would have answered immediately. Separating them costs an hour once.

Asking the report a question directly

Most of the time spent with this data is not analysis. It is navigation — finding the view, setting the filter, remembering where last month's comparison lives. An assistant that accepts plain-language questions removes that step: each question pulls between zero and three data blocks depending on what it actually needs, and the last twenty messages stay available as context.

• Ask in the language you think in. The question can be in English even when the underlying queries are German. That alone removes the largest practical barrier for an international team.
• Four filters narrow the scope. Enough to isolate a language segment, a period and a property without building a saved view for every combination.
• Twenty messages of history. Enough for a follow-up chain; if you routinely hit the limit, the original question was too broad and should be split.
• Zero blocks is a valid answer. Some questions are answered from context alone, and not loading data is faster than loading it unnecessarily.

For a weekly review this replaces most of the clicking. The question becomes "which German queries gained impressions but lost clicks last month" rather than a sequence of filter selections — and because the phrasing is recorded, the same review can be repeated identically four weeks later. Running that review inside the same workspace that holds the tracking data means the follow-up question does not require switching tools.

What the first thirty days look like

Week two is the one that changes how the company thinks. Until the language split exists, German demand is an anecdote someone mentions occasionally. After it exists, it is a number with a size, and the decision about whether to serve it becomes an ordinary prioritisation question rather than an argument about strategy.

Which queries are realistically reachable is a separate question from which ones you currently appear for, and it is answered by keyword research rather than by the report. Where the two disagree — strong demand, no page, no impressions — is where the next quarter's work sits, and turning those gaps into pages is what content strategy covers. Reading the report in one connected environment keeps all three views on the same screen instead of in three separate tools.

Open your query data by language

Questions from teams working across two languages