What Is Topical Authority?

Where the term came from

Before it caught on in SEO, this exact phrase already existed in academic literature, in a different context entirely: citation ranking and author credibility, not search rankings.

One relevant paper is "Joint Modeling of Topics, Citations, and Topical Authority in Academic Corpora," by Jooyeon Kim, Dongwoo Kim, and Alice Oh, published in Transactions of the Association for Computational Linguistics, Volume 5, 2017. It uses the same phrase, but for ranking author credibility within an academic subject, not for ranking anything in Google.

That usage comes out of citation graphs and stays entirely inside academic research. It has no connection to Google rankings or SEO.

In classical Information Retrieval literature on web ranking, the relevant concepts were things like Topical Relevance and document clustering, not Topical Authority in the sense used today.

From here on, every claim in this article either has a primary source or is explicitly marked as interpretation.

Authority in Information Retrieval vs. Authority in SEO

In Information Retrieval literature, authority has a fairly precise meaning, tied to graph structure. Algorithms like PageRank and HITS derive authority from link patterns, not from the text itself. HITS even defines two separate roles explicitly: hub pages and authority pages.

In SEO writing, the same word gradually picked up a different meaning, closer to topical expertise. That shift happened without anyone announcing it, and it's the source of a lot of today's confusion.

The practical consequence matters. When someone says a site has authority in a topic, they could mean two very different things: other sites in that space link to it, or the site's content is tightly organized around a single semantic core. The first is something others give you. The second is something you build yourself.

Google's official position

Google's rejection of "Topical Authority" as a named system or concept doesn't, by itself, tell us whether separate mechanisms relevant to topical focus exist. It only tells us Google hasn't packaged anything under that name officially. The sections that follow investigate those mechanisms independently.

Why no single score doesn't mean no mechanism

A simple comparison makes this clearer. A car doesn't have a component called a "safety score." It has brakes, airbags, a body structure. But saying the car is safe isn't a meaningless statement. You're just naming an emergent property with a single word.

Topical Authority, in its modern SEO sense, works the same way. The same phrase existed earlier in academic literature, and SEO later adopted and popularized it with a different meaning. This article doesn't claim the SEO usage descended directly from that academic framework, only that the phrase itself predates it. The rest of this article looks at several separate Google mechanisms that may be relevant to parts of what SEOs discuss under that label. That's not a claim that Google designed those mechanisms together, that they form one documented architecture, or that Google refers to their combined effect as Topical Authority internally.

Topical Authority vs. Topical Coherence

This distinction was raised by Carolyn Holzman and adopted by Shaun Anderson in his writing. In my view, it's the most important conceptual correction in this space in recent years.

The logic is simple. Authority is granted to you. You can't decide to be authoritative. Topical coherence, on the other hand, is a design choice. You decide what your site is about and what it isn't, then you build the structure so that decision is legible.

How this article uses the term

From here forward, whenever I write topical focus, I mean how closely a site's content clusters around a single semantic center. Content vectorization is how this article models and approximates that idea, not a confirmed Google formula for computing it.

Whenever I write topical coverage, I mean how completely a site's content addresses the space of possible questions within a topic.

The two are independent, and later on we'll see them come into direct conflict.

This topic is often explained from the middle. The discussion jumps straight from the idea that Google can infer topical focus to practical recommendations, without first asking what problem those mechanisms might be solving.

The earlier state of things

In the DOJ's antitrust case against Google, a set of internal presentations became public. One of them is from Eric Lehman, a senior search engineer.

What that presentation describes is striking, for anyone who's spent years reading about how Google understands language. Lehman states plainly that the system doesn't understand documents, it simulates that understanding. Instead of reading a document, Google records and retains how humans react to it.

The logic was straightforward: if user reactions to a document are positive, the document is probably good. If negative, probably bad.

The Cold Start problem

That same presentation acknowledges the weakness in this architecture. When a document is new, recently changed, or hasn't been shown much yet, there's no behavioral data. The system is effectively blind.

This is what's called Cold Start in machine learning. A system that depends entirely on feedback has nothing to go on for new input.

For Google this wasn't just a technical footnote. Millions of new pages get published every day. A system that can't judge a page until behavioral data starts coming in is, in practice, missing a huge part of the web.

My hypothesis: a semantic layer

Up to this point, what's documented in Lehman's presentation is a description of the problem, not a solution. The document itself says nothing about how Google actually solved it.

From here, this is my interpretation. For the system to make a judgment about a document before any clicks exist, it needs to move from raw text to some numeric representation that's comparable across documents. If a new page has no history of its own, is there anything else that does? My hypothesis is that the answer is the site.

If the system knows what a domain has published in the past, and what happened to that content, it can build an initial estimate for a new page. This assumption needs to be weighed against the site-level fields in the leaked documentation, which the following sections cover.

Two separate dimensions in ranking

Court testimony and case documents let us draw out a useful distinction. Rather than treating Google's ranking as a single equation, it helps to separate out two analytically distinct dimensions, each answering a different question. This is exactly the distinction this section wants to draw out.

The first question is whether this source can be trusted. That's the Quality/Trust dimension, and it behaves as comparatively independent of Query. For a given site, the answer tends to hold fairly steady across different searches, rather than being recalculated from scratch each time.

The second question is whether this document is relevant to this specific query, that's the Relevance dimension. It's entirely query-dependent and gets recalculated for every search.

Say your traffic drops. If you don't know which dimension the problem sits on, you'll spend six months working on the wrong thing.

If the problem is on the Quality dimension, producing more topically focused content won't help. If the problem is on the Relevance dimension, working on trust and transparency won't fix it either.

Court documents and testimony

What's described here isn't analyst speculation. The source is the DOJ's antitrust case against Google, case number 1:20-cv-03010-APM in the District of Columbia.

Two kinds of documents entered the public record during that case. One is Exhibits, internal presentations and documents that were created for internal use and later unsealed. The other is sworn testimony from executives and senior search engineers, given under oath. What makes these sources valuable is that, unlike interviews or blog posts, the testimony was given under oath and the internal documents were written for internal use, not public relations.

These same documents also reference a third dimension, related to popularity and the breadth of references, tied more to the link graph and browser usage data. It's mentioned here for completeness. It isn't the subject of this article.

Anchor, Body, and User Interaction signals

In a presentation titled "Life of a Click" (May 15, 2017), another document from the same case, the basic ranking structure is split into three columns. The first is the document's Body, what the document says about itself: text, title, headings. The second is Anchors, what the rest of the web says about that document. The third is User Interactions, what users say about the document through their behavior.

The query lifecycle, and where topic enters it

When a user enters a query, several stages happen before results appear.

1. The query gets interpreted, and sometimes rewritten or split into sub-queries.
2. Out of billions of documents, a set of candidates gets pulled (Candidate Generation). This stage has to be fast, so it runs on cheap signals.
3. Candidates get scored (Ranking). This is where more expensive, precise signals come in.
4. Re-ranking layers get applied, things like freshness or historical user behavior.
5. Filters like result diversity run, so one domain doesn't take over the page.

For this article, the useful hypothesis is that topical relevance can matter at more than one stage of this process, once at Candidate Generation, where it may help you get considered at all, and again at Ranking, where it may affect where you place. I want to be clear this is an interpretation layered on top of the documented stages, not a documented two-point pipeline for how topic specifically enters the system.

Retrieval vs. Ranking

This is a useful practical distinction to take from this section. Retrieval is the stage where the system decides whether you enter the competition at all. Ranking is the stage where it decides how you place in that competition.

To understand what today's fields actually do, it helps to know how the system used to detect topic, and why those earlier methods weren't enough. This path starts with simple word counting and ends at vectors, moving through several different ways of representing and matching topical information along the way.

The statistical era

The oldest method was counting. If a word shows up often in one document and rarely across the rest of the collection, that document is probably about that word. That's the logic behind TF-IDF, and a more refined version of it, BM25, factors in document length and diminishing returns from repetition.

Lexical, count-based methods like these are computationally cheap, which is useful for Retrieval in general, where speed matters. But they share one fundamental weakness: no understanding of meaning. To this method, "car" and "automobile" are two completely unrelated strings.

A myth that needs to die

SEO content still refers to LSI constantly, and has even invented a term for it, "LSI keywords." "LSI keywords" is SEO jargon, not a concept or keyword category that Latent Semantic Indexing, the actual mathematical technique, ever defined.

LSI is a real mathematical technique from the late 1980s, based on singular value decomposition applied to a document-term matrix. But first, there's never been any evidence that Google uses it at web scale. Second, the technique isn't computationally practical for a document collection the size of the web. Third, nothing called an "LSI keyword" is defined anywhere in that method. What tool vendors call "LSI keywords" is usually just statistical word co-occurrence.

Phrase-based Indexing

Anna Patterson's work at Google marks one important step in this progression. The idea was to index phrases instead of individual words, and, more importantly, to keep a set of related phrases for each one.

Within that model, a document about internal combustion engine would be expected to also contain phrases like crankshaft and cooling system. The presence or absence of expected, related phrases can serve as evidence about how well a document fits a topic.

My interpretation is that this is where the concept of Topical Coverage, as defined in this article, first gets a technical foundation. Neither Patterson nor her patents use the terms Topical Coverage or Topical Authority, this is a connection I'm drawing between that work and the concept this article tracks. A document that's good on a topic, in this model, is one that contains the phrases you'd expect for that topic.

Enter the vector

The next stage was converting text into numerical vectors. The core idea: place words, and later sentences and documents, as points in a space with hundreds of dimensions, such that distance in that space corresponds to semantic similarity.

With this, similarity between two documents no longer depends on shared words. Two articles can share no words at all and still land close together as vectors.

Entities

The next layer is entities. What separates an entity from a keyword is that an entity refers to an actual thing in the world, not just a string of characters.

In the leaked documentation, there's a field that attaches identified entities to page content. That means the system doesn't just see the string "Saadi" appear in text, it identifies which Saadi.

A multi-layer intent model

The traditional split of search intent into informational, navigational, and transactional has been repeated in SEO training for years. It's useful as a starting point, but too coarse for serious work.

In the leaked documentation, there's a field called asteroidBeltIntents. Based on the name and its surrounding context, my inference is that it points toward a more granular way of classifying document intent than the traditional three-bucket model, though this is my reading of the name, not an official description of what the field does. Google hasn't published details of a granular intent model tied to this field. The details of how it actually functions aren't documented.

Why page-level vectors weren't enough

Now we get to the point this whole article turns on. Say you have a page whose vector sits exactly at the center of the tax accounting topic. Great. But that page is published on a site where ninety percent of the content is about cooking.

A page-level vector doesn't see that mismatch. To catch it, you'd need something like a domain-level vector, and a way to measure how far the page sits from it. That's where fields such as siteFocusScore and siteRadius, covered next, become relevant to the hypothesis developed here. Their names and existence are documented, the exact way they function is not.

Site Quality and Reference Queries

This family, often attributed to the Panda algorithm, introduces a concept that's central to our discussion. The core patent is "Site quality score," US9031929B1, invented by April R. Lehman and Navneet Panda, assigned to Google, with a priority date of January 2012 and granted in May 2015. The patent describes categorizing queries as referring to a particular site, and associating other queries with that site as well, including through user selections of that site's results. A ratio built from those counts can then be used to compute a Site Quality Score.

Two things about this idea tend to get overlooked. First, the measure is relative, not an absolute number. A small site in a narrow niche can score well. That's good news for specialized sites in any language.

Second, and this is my interpretation, not something the patent itself states, the patent uses these query associations to compute a Site Quality Score, not to define a site's topic. Those same query associations may also reveal something about how a site is perceived topically. That's my interpretation, not the purpose the patent assigns to the score.

Phrase-based Indexing and topical clustering

The core patent here is "Phrase-based indexing in an information retrieval system," US7536408B2, invented by Anna L. Patterson, assigned to Google, initially filed in July 2004. My interpretation is that this family is the technical foundation of the Topical Coverage concept as defined in this article, though the patent itself never uses that term. Its central claim is that for any phrase, you can build a set of related phrases, and judge a document's topic based on whether or not those phrases show up.

The less well-known part is that this same structure is also used for document clustering. Documents with similar phrase patterns get grouped together.

What this family supports is that the system holds a specific expectation of vocabulary for a given topic. What it doesn't support is that packing in more phrases is automatically better. A related patent from the same inventor, "Detecting spam documents in a phrase based information retrieval system" (US8078629B1, granted December 2011), addresses spam detection through unusually dense phrase repetition explicitly.

Website-level representations and classification

The patent in this family is a patent application, not a granted patent: "Website representation vector," publication number US20200050707A1 (international publication WO2020033805), invented by Yevgen Tsykynovskyy, assigned to Google LLC. My interpretation is that this family is the most direct technical precedent for what we now call topical focus, though the application text never uses that term. The core idea is that content from a website, including its domains and subdomains, can be used to build website-level representations, which can then be classified within particular Knowledge Domains.

What matters here is that this kind of website-level classification isn't a new idea discovered when the leaked fields surfaced. It existed in patent literature years earlier.

What this application directly supports is that classification can happen using website-level representations placed within particular Knowledge Domains. What it doesn't support is that every site gets a single label, the text notes a site can receive different scores or classifications across different Knowledge Domains. But that point sits more in the description of the invention than in an independent patent claim, and reading this as evidence for a concept like Topical Focus is my own interpretation and extension of it, not the application's core claim.

The Information Gain family and the logic of non-repetition

The core patent here is "Contextual estimation of link information gain," application number US20200349181A1, granted as US11354342B2, assigned to Google. This family addresses a question that's become critical in an era of mass content production: relative to information a user has already been presented with or viewed in a given context, what does an additional document add?

The logic is contextual: a document's Information Gain is estimated against what's already been presented to or viewed by a user in that specific context, not against the web as a whole. A document that only restates information already covered in that context contributes little by this measure.

The Query Variants family

The core patent here is "Generating query variants using a trained generative model," US11663201B2, assigned to Google, initially filed in 2018 with a priority date of 2017, granted in May 2023. This family covers generating variants of a query using a trained generative model, variants can take different forms, such as equivalent phrasings, follow-ups, generalizations, canonicalizations, clarifications, specifications, or translations. Some implementations described in the patent can obtain search-system responses for these generated variants.

My interpretation is that this connects conceptually to Topical Coverage: if a search system explores a broader set of information needs related to a query through generated variants, content that addresses that broader set has more conceptual surface area to be relevant to. That's a connection I'm drawing, not something the patent claims about ranking or selection.

Patent family summary tableWhat each claim supports and doesn't support

The third column is there deliberately. Most writing about these patents only covers the second column. It's the third column that prevents misuse.

In 2024, a large volume of Google's internal Content Warehouse documentation surfaced unintentionally. What surfaced was data structure definitions, not algorithm code. This distinction matters. We know what gets stored. We don't know at what weight, or at what stage, it gets used.

The underlying engine

The leaked documentation contains a field called site2vecEmbeddingEncoded. The name is consistent with an encoded site-level embedding, a vector representation of some kind. My interpretation is that this represents a site's topical identity, the documentation itself doesn't describe it in those words. Its exact contents, how it's constructed, what role it plays, and whether it's still in current production use aren't established by the identifier alone. This field is relevant to the hypothesis this article develops about site-level semantic representation, not confirmation of it.

The same documentation also contains another field, asteroidBeltIntents, which came up in the previous section under the multi-layer intent model without naming it directly. The field name is documented, what we can infer about its function comes, to some extent, from the name and its surrounding context, not from an official description. My cautious reading of the name and surrounding context is that it may relate to a more granular way of representing or classifying intent. Exactly how many dimensions it has, how it affects ranking, or whether it's still in use today, isn't documented.

Topical Focus

The siteFocusScore field exists in the documentation. Its name suggests some kind of site-level focus-related score. Reading that as a measure of topical concentration, high value meaning specialized, low value meaning general or scattered, is my inference from the name, not something the documentation states directly. The exact computation, scale, directionality, and any thresholds aren't established here, and neither is whether or how it's used in current production. Wherever this article later uses "focus" as a practical concept, that's this article's own model and proxy, not a description of Google's metric.

Three common misreadings are worth ruling out regardless of how the field actually works. The identifier itself doesn't establish this score as a quality measure, this article keeps topical focus and quality as separate concepts, the next section covers that distinction in detail. A high value on a concept like this wouldn't automatically be desirable either, a site fully focused on a topic with zero demand would still have zero traffic from that topic. And this number can't be viewed directly by any tool. Any tool claiming to show you this number is showing you its own estimate.

Topical Radius

The siteRadius field exists in the same documentation. Its name suggests some concept of radius or distance, but the identifier alone doesn't establish what it measures, at what level it's computed, or how, if at all, it relates mathematically to siteFocusScore. I don't have a documented basis for describing a page-to-center distance or a site-wide aggregation formula here, so I won't present one as fact.

The solar-system metaphor, and where it breaks

For the model I use in this article to reason about focus and radius conceptually, a solar-system metaphor is useful: a central topic as the sun, each page as a planet, distance from center as some form of semantic distance. This is my own conceptual scaffolding for thinking about these ideas, not a reconstruction of how Google's fields are actually computed, and it shouldn't be read as one.

Two things about the metaphor are worth flagging if you use it the way I do. First, in an actual solar system, the sun exists independently of the planets. In this model, the center would be computed from the content itself, which means changing enough of your pages could shift where that center sits. Second, distance in a high-dimensional vector space doesn't behave like two-dimensional intuition. Any diagram of this is a simplification for explanatory purposes, not a picture of an underlying Google architecture.

Four conceptual site patterns

This is a framework I use for reasoning about a site's topical shape, not a set of states Google's fields are documented to produce. Before reading on, you might guess which pattern feels closest to your own site. The measurement section later gives you a way to check that guess against your own content.

The NSR family and the ambiguity around "chunk"

The same documentation contains a family of fields prefixed NSR. Google has never officially expanded this abbreviation. Secondary analysis usually reads it as "normalized site rank," but that reading isn't confirmed. At least one well-known analyst has proposed an alternative guess, "Neural Semantic Retrieval." From here on, I'll just use the abbreviation NSR itself.

Within this family, there are structures that appear to distinguish or segment parts of a site or host. This is relevant to the possibility that different sections of a site could be represented separately in some way, I want to be careful not to state that as confirmed ranking behavior, since the documentation doesn't establish how, or whether, that segmentation actually affects ranking.

Now, an ambiguity worth resolving. In SEO writing, the word "chunk" gets used for two entirely different things, and it's a widespread source of confusion. One is splitting text into small pieces for retrieval in vector-based systems, that's what most people mean when they say "chunk." The other is fields in this same documentation that appear to relate to domain-level segmentation, splitting a site into sub-sections for signal computation. There's no evidence here that the two uses are related, beyond sharing a name.

Vector versioning

Some site-level fields in this documentation have a data type indicating that version information is stored alongside the value. This may indicate some form of version tracking. It doesn't, by itself, establish that Google retains a historical sequence of prior values, or that any such history functions as a ranking signal.

I gave this its own section because, in my view, it's the single most important correction of thinking a reader needs here.

Topical Focus is not the same as Quality

Say you build a site that's entirely about one narrow topic, with 100 fully focused articles. Your Topical Focus, by this article's working definition, is close to complete. Now say all 100 of those articles are shallow, rewritten from other sources, and unsourced. Does Topical Focus alone tell you this site will do well?

Not by this article's logic. Focus, as defined here, answers what a site is about, not whether it's any good. Topical Focus doesn't guarantee Quality, Trust, or ranking success.

A general site with high Trust and broad Topical Focus

Take a large general-interest newspaper. Politics, sports, business, food, everything. By this article's working definition, its focus would be broader and less concentrated than a narrow specialist site. Yet these sites rank well for a huge range of queries. If narrow Focus were the only path to ranking success, that wouldn't be possible.

Here's my explanation, and this is interpretation, not a documented claim: these sites score very high on some other dimension, and in my view their topical pattern is still recognizable, something like a legitimate general-interest media pattern. The Site Classification patent family covered in the patents section (Website representation vector, US20200050707A1) shows that this kind of classification is technically possible, but it doesn't establish that Google actually uses this exact category in live ranking today.

The reverse case: a fully focused site with thin content

The opposite scenario is just as instructive, and far more common on sites I've seen produced for local markets. Build a site about one narrow topic with 200 fully focused articles. Its Topical Focus is close to complete.

If those 200 articles are just rewrites of existing material, with no sourcing, no original data, and no first-hand experience behind them, that site won't rank. And worse, the owner will never understand why, because they've followed every piece of conventional advice.

The anomaly effect

Here I want to separate documented fact from inference. What's documented is that the leaked material contains site-level fields and structures. What's inference is that a site with an unusual topical mix doesn't fit any recognizable pattern in this framework, and that, in my view, makes it harder to reason about.

I've seen this pattern firsthand: a site with half legal content and half fitness content. Neither category is a problem on its own. But that combination doesn't match any recognizable pattern in the framework I use here.

Quality Ceiling

There's a point I won't go into in detail, since it's outside the scope of this article, but leaving it unmentioned would be misleading. In the same documentation, there are fields whose names suggest some form of Quality measurement at the site level, and some of these appear to include version or period-related information alongside their values.

I want to be clear about what that does and doesn't establish. It doesn't confirm that Google maintains a running historical Quality score, that low historical Quality creates a fixed ranking ceiling, or that improving Topical Focus can't overcome a weak history quickly. What I take from this, as my own practical hypothesis rather than a documented Google mechanism, is the idea of a "Quality Ceiling", a way of thinking about sites with a weak historical track record, where I'd expect recovery to take longer than a quick structural fix. If you're working on a site with a troubled history, I'd factor that possibility into your timeline expectations, cautiously.

An industry name, not a documented mechanism

Unlike other concepts in this article, the term "Coverage Authority" doesn't even have a solid secondary source behind it, and it isn't a documented Google term or mechanism. Where it's useful is that it points, loosely, toward a real technical mechanism this article connects to it conceptually, the Query Variants patent family covered earlier. Don't take the name itself too seriously. Take the underlying mechanism seriously, and keep in mind that the link between the two is this article's interpretation, not a documented equivalence.

Depth vs. breadth

Before anything else, you need to know that Coverage pulls in two directions that compete with each other, because your resources are limited. Breadth means how many subtopics you touch. Depth means how far you take each one.

A team that can produce 10 articles a month can either touch 10 subtopics once, or fully cover 3. Both choices are legitimate, but they lead to different outcomes.

Three types of Coverage that get confused with each other

These three shouldn't be conflated, because each answers a different question, and satisfying one doesn't mean the others are satisfied too. This is an analytical framework for thinking about coverage, not a documented Google metric.

Query Coverage means what percentage of a topic's queries your site has content for. This is the simplest and shallowest measure.

Entity Coverage goes deeper. It means what percentage of the entities relevant to that space your site actually covers in substance, not just mentions by name.

Intent Coverage is the hardest and most valuable. It means how many distinct intents within a topic your site has a genuine answer for, rather than one page trying to answer all of them at once.

Coverage and Query Variants

The Query Variants patent describes generating variants of a query using a trained generative model, some implementations described in the patent can obtain search-system responses for these generated variants. It doesn't establish a fixed query-decomposition pipeline, and it doesn't establish that each variant represents a separate, guaranteed retrieval opportunity.

My interpretation is that this connects conceptually to Coverage: if a search system can explore a broader set of query variants around a topic, content that addresses more of that broader set has more conceptual surface area to potentially be relevant. That's a connection I'm drawing, not something the patent claims about selection odds or ranking.

The Coverage ceiling, where volume strategy breaks down

Here's the point I think matters most in this section. Common advice coming out of courses and articles in this space is to complete your topic map and publish it as fast as possible. The logic is that until the map is complete, you won't see results.

The leaked documentation contains a module called QualityCopiaFireflySiteSignal that holds site-level signals. My interpretation, not something the documentation states in these words, is that these signals may be relevant to detecting scaled-content patterns. Two fields within it bear directly on this piece of advice.

The numOfUrlsByPeriods field records the number of discovered URLs across consecutive 30-day periods, essentially the pace of page-count growth. The numOfArticlesByPeriods field counts pages that crossed a specific quality threshold, reported in secondary sources as a score of 0.8 or higher, over those same 30-day periods. I want to flag that the 0.8 figure comes from secondary reporting, not an official Google statement, and I'm not treating it as a confirmed threshold.

What I take from the existence of these two fields side by side, as my own analytical proxy and not a documented Google signal, is a way of comparing your publishing volume against the volume of content that meets the reported quality condition. I'm not claiming Google computes, stores, or uses this ratio itself, only that it's a useful lens for reasoning about your own output.

The saturation point and diminishing returns

Within a defined topic, the set of genuinely distinct information needs can, in my experience, become increasingly exhausted over time. As that happens, additional pages may become more repetitive or marginal relative to what's already there.

By analogy with the Information Gain concept covered earlier, I'd expect a document's incremental informational value to decline in that kind of context. Continuing to expand coverage past that point may also push content toward more tangential areas, by this article's model, though I wouldn't call either of these inevitable, they're patterns I've observed rather than fixed rules.

Spotting this saturation point is hard, but there's one practical tell I rely on. When you find yourself pulling the next article's title out of the previous one and just rewording it, that's usually a sign you've reached it.

Why Coverage without Quality dilutes Focus

This section connects Coverage and Focus, and explains why the two sometimes end up in conflict, within the model this article uses. In this article's own vector-based approximation, not a documented Google formula, I treat a site's topical center as something that shifts based on the content published around it. I introduced this idea under the solar-system metaphor, and here's where it plays out in practice, within that model.

When you add tangential content in pursuit of more Coverage, two things happen at once, in this model. First, the new pages carry a large Radius, by this article's framework. Second, and more importantly, the modeled center itself shifts toward them. That would mean your core pages, without a single word changing, end up modeled as further from center than before.

Why a good page might get less visibility on a scattered site

Cold Start itself, as covered earlier, is historically documented. Connecting it to site-level topical identity is my hypothesis, not something Google has confirmed. Within that model, a coherent site could offer a more useful prior for reasoning about a new page, while a scattered site could offer a less informative one. I'm not claiming Google definitely uses domain identity to set an initial score, that a page receives a lower starting position, or that it has to "make up" any specific deficit through Behavioral Data. This is a hypothesis about how topical coherence might matter, not a description of a documented ranking sequence.

Where a multi-topic site works

The short answer is that it works when each topic has enough volume and quality to form its own recognizable pattern on its own terms. Multi-topic sites aren't inherently a problem, plenty work fine. As a rule of thumb from my own experience, not a Google threshold, if your second topic has only 15 articles, that's not a second specialty yet, it's more likely a deviation from the site's main focus. I want to be clear this number is a practitioner heuristic I use, not a documented Google cutoff.

Subdomain or subdirectory

This old question gets a clearer answer within the framework this article has built, though it's still not a universal rule, and this is a site-architecture and organizational choice, not a claim about how Google treats subdomains for ranking purposes. If your two topics genuinely represent two separate businesses, and each has enough volume and quality on its own, a subdomain can create a cleaner organizational boundary between them, at least from a structural and user-experience standpoint.

If one of the two topics is small, spinning off a subdomain for it can fragment a limited amount of content and make that section harder to establish as a meaningful property in its own right. In that case, a subdirectory tends to work better, or simply not building out that content at all.

Old off-topic content

This is the most common question I hear in consulting sessions, and it's also where the most common wrong answer shows up, the advice to delete anything off-topic. That answer is wrong because it ignores other variables that matter. I've laid out the decision tree for this in the execution framework section.

The Topic Map, without the mythology

A Topic Map isn't complicated. It's a conceptual model of your subject area, one that lays out what exists within that space and how those pieces relate to each other.

What separates it from a keyword list is that its unit is the concept, not the search phrase. Two different search phrases can represent the same concept, and one search phrase can carry several concepts inside it.

1. Write out the list of entities in your subject area. For collision insurance, that's things like insurance company, policy, claim, adjuster, deductible, add-on coverage, and so on.
2. For each entity, write out its attributes. How many types of deductible exist, how it gets calculated, whether it's adjustable.
3. Map the relationships between entities. Which entity is a prerequisite for which.
4. Only now, go to your query data and see what people actually ask about each node. If a node has no search demand at all, note it down but put it at the bottom of the priority list.
5. For each node, decide whether it needs its own page or belongs as a section within another page. Base that decision on how different the intent is, not on search volume.

A critique of the hub-and-spoke model

The common model is to build a parent page with child pages linking to it. This works in plenty of cases, but it has two shortcomings that don't get talked about enough.

First, it imposes a tree structure on something that's often actually a network, not a tree. Many concepts relate to several other concepts, not just one parent.

Second, when this gets executed mechanically, the parent page turns into a list of links with throwaway intro text, a page nobody reads that exists purely for the sake of structure.

Internal Linking, two separate functions

Internal Linking does two different things, and they shouldn't be conflated. The first function is redistributing importance, internal links can pass PageRank-like importance, or link equity, around a site, similar in logic to how PageRank works. The second function is signaling a semantic relationship. Anchor text and surrounding context can provide evidence about how two pages relate to each other, though not a guaranteed or fixed interpretation.

Signal consistency

A page's title, its main heading, and the anchor text pointing to it from elsewhere should point at the same topic and intent, without contradicting each other. The wording doesn't need to match exactly, what matters is that none of them frame the page as being about something different. This is the simplest and cheapest thing you can check, and it gets overlooked surprisingly often on sites I've worked with. I've seen a page whose title was about a tutorial, whose heading was about a purchase, and whose internal anchor text pointed at pricing, three different framings for one page.

Taxonomy, URL structure, and categorization

Your category structure is your formal statement about the site's topical organization. If your categories don't match the reality of your content, you're sending a conflicting signal. In my experience, I usually don't find a separate category useful when it contains only 2 or 3 items, this is a practitioner heuristic I use, not a documented Google minimum. Either skip a category that thin, or merge it into a broader one. Category structure by itself doesn't create topical authority.

Publishing order

A question I get asked a lot is whether it matters which article you publish first. The honest answer is there's no direct documentation on publishing order. What exists is this indirect line of reasoning, entirely within the vector model this article uses, not a description of how Google actually computes anything.

Within that model, a site's modeled topical center shifts based on its content. In a site's early days, with only a handful of articles, each one carries more relative weight in shaping that modeled center simply because there's less existing content to average against. As a site grows into the hundreds of articles, the modeled impact of any single new article shrinks.

The practical takeaway, as a rule of thumb from my own experience rather than any documented Google threshold, is that your first 10 to 20 articles do a lot of work in shaping a site's early topical identity. Publish scattered content during that early stage, and you risk shaping a blurrier identity that costs more to fix later. This is an inference, not something documented, but it's an inference with essentially no downside, since starting from your core is a sound approach regardless.

Supporting pages vs. revenue pages

Every Topic Map has two kinds of pages, and confusing them is one of the more costly mistakes you can make. A revenue page connects directly to income, product pages, service pages, campaign landing pages.

A supporting page doesn't make money on its own, but it does three things: it serves informational needs earlier in the decision journey, it fills out the site's informational structure around its commercial topics, and it creates useful internal-link paths toward revenue pages.

What can actually be cited

The leaked documentation contains a field called authorObfuscatedGaiaStr, whose name is consistent with a structured author identifier. That suggests the system holds an author as an entity separate from the page itself. That's the most that can be said with confidence. What use is made of this identifier, and with what weight, isn't documented. This identifier doesn't establish an author authority score, a reputation score, an E-E-A-T score, or that author identity functions as a ranking factor, it establishes that a structured author-related identifier exists in the documentation, nothing more.

Site Credibility vs. Author Credibility

These two shouldn't be treated as one thing. A site can be tightly focused on a topic while its authors have no recognizable track record at all. The reverse is possible too.

A practical point worth flagging: a genuine subject-matter expert can easily have little or no visible digital footprint, this is especially common in fields and languages where expert commentary hasn't traditionally moved online. In that situation, I'd generally prioritize making that person's real-world identity and expertise more clear and verifiable over simply producing more content. I'm not claiming this guarantees any particular ranking outcome, or that Google directly rewards digital presence, only that it's a reasonable prioritization call in cases like this.

A common mistake

Building a fake author, complete with a photo and a fabricated bio, to simulate expertise that doesn't actually exist. Setting the ethics aside, a fabricated profile doesn't establish real expertise, reputation, or credibility, and a bio the site wrote about itself isn't independent evidence of any of those things. Genuine external evidence, references to a real person that exist outside your own site, can make an identity more independently verifiable, but I'm not claiming a specific Google ranking mechanism or author score built on that. I also wouldn't assume every fabricated persona necessarily has zero external footprint, some do get built up over time. The core problem is simpler than any ranking mechanism: a fabricated author isn't a substitute for a real one.

Everything up to this point has been conceptual. From here on, it's tooling.

What you can't actually measure

None of the fields named in this article are visible from outside Google. No tool has access to them. So anything we build here is a homemade proxy. We're constructing a metric with similar logic, just so we can tell which direction we're moving in. Our number isn't the same as Google's internal number, and it isn't meant to be. Tracked over time, this kind of proxy is mainly useful for comparing a site against its own past self, not for reading Google's internal trend. Movement in this metric doesn't necessarily reflect movement in whatever Google's internal representation actually is, and it doesn't establish anything about ranking causality on its own.

Measuring Topical Focus with Google Search Console data

The simplest method, and it needs no extra tooling. Export your queries from the last 16 months. Use query clustering, manual or automated, to group them into topical clusters. Now check what percentage of your total impressions falls within your largest cluster.

If that number declines over time, by this homemade metric, your observable Topical Focus is diluting, even if total traffic stays flat. I want to be clear this is a proxy of my own design, it doesn't expose Google's siteFocusScore, and Search Console has no way to reveal that field directly.

Impression Share across a topic's query set

The previous metric gave you overall focus. This one measures your standing within one specific topic. Build a list of queries for that topic, from your own query data and from keyword research. Now pull two numbers: what percentage of those queries you get any impressions for at all, and what your total impression volume is across that set.

The first number reflects your Coverage, by this proxy. The second is an observable visibility signal within that query set, worth treating as one input rather than a pure measure of strength, since total impressions can also be shaped by search demand, query mix, seasonality, and how coverage happens to line up with what people are searching. A high first number paired with a low second number, where you're showing up broadly but with little volume anywhere, may be worth investigating as a sign that depth is missing, in the sense covered in the depth-versus-breadth discussion earlier, though it's not a diagnosis on its own.

Measuring semantic distance from a site's center

Here's a method for putting a number on the Radius idea covered earlier, as a practitioner approximation, not a reproduction of anything Google does internally. We convert each page's text into a vector, treat the average of all vectors as an approximate site center, and calculate each page's distance from that center.

#  pip install sentence-transformers trafilatura numpy requests

import numpy as np
import requests
import trafilatura
from sentence_transformers import SentenceTransformer

MODEL = "intfloat/multilingual-e5-large"
model = SentenceTransformer(MODEL)


def fetch_text(url: str, max_chars: int = 6000) -> str | None:
    try:
        html = requests.get(url, timeout=20).text
        text = trafilatura.extract(
            html, include_comments=False, include_tables=False
        )
        return text[:max_chars] if text else None
    except Exception:
        return None


def embed(texts: list[str]) -> np.ndarray:
    prefixed = [f"passage: {t}" for t in texts]
    return model.encode(prefixed, normalize_embeddings=True)


def analyse(urls: list[str]) -> list[dict]:
    pages = []
    for u in urls:
        t = fetch_text(u)
        if t and len(t) > 300:
            pages.append({"url": u, "text": t})

    vectors = embed([p["text"] for p in pages])

    centroid = vectors.mean(axis=0)
    centroid = centroid / np.linalg.norm(centroid)

    for page, vector in zip(pages, vectors):
        similarity = float(np.dot(vector, centroid))
        page["similarity"] = round(similarity, 4)
        page["radius"] = round(1 - similarity, 4)
        del page["text"]

    return sorted(pages, key=lambda p: p["radius"], reverse=True)


def focus_score(results: list[dict]) -> float:
    return round(float(np.mean([r["similarity"] for r in results])), 4)


if __name__ == "__main__":
    urls = [line.strip() for line in open("urls.txt") if line.strip()]
    results = analyse(urls)

    print(f"focus score: {focus_score(results)}")
    print("\noutliers:")
    for r in results[:20]:
        print(f"{r['radius']:.4f}  {r['url']}")

This uses intfloat/multilingual-e5-large as the embedding model, with the passage: prefix convention and normalized cosine similarity, this is entirely this article's own measurement method, not a reconstruction of Google's embeddings. A page scoring well on this script tells you nothing about how it scores against Google's actual internal representation, whatever that representation may be.

The Publishing Velocity vs. Quality ratio

A practitioner proxy inspired by the period-based fields discussed earlier in this article, not a reproduction of them. It's simple and needs no tooling. For each of the past several months, log two numbers: how many URLs you published, and how many of those crossed some success bar you define yourself within that same period. The bar is entirely up to you, for example, a page that picked up at least 100 impressions in its first 3 months is just one possible example, not an approximation of any Google quality threshold.

If the first column climbs steeply while the second stays flat, that resembles the high-risk pattern described earlier in this article's framework, by this same proxy logic.

Diagnostic signals worth investigating

These patterns are worth looking into, not proof of topical dilution on their own, they can also result from demand shifts, seasonality, ranking changes elsewhere, indexing changes, or a site simply expanding into new territory.

• Your largest topical cluster's share of total impressions declines month over month.
• The number of unique queries you get impressions for rises while total clicks stay flat, which could mean you're showing up more at the margins than in your core.
• Average position on core queries gets worse while average position on peripheral queries improves.
• The ratio of indexed pages to pages actually getting impressions declines.

A realistic timeframe for seeing an effect

Structural and topical changes tend to take a while to show an effect. In my experience, I usually want several months of data before judging a structural change, for a site with a few hundred pages, 6 months has been a reasonable rough review window for me. For a larger site, I'd expect to need longer. I'd be skeptical of anyone promising a durable Topical Authority outcome on a fixed six-week schedule, that's professional judgment on my part, not a documented Google rule about timing.

• There's a score called Topical Authority, and it can be measured.

  This article hasn't found evidence of a single measurable Google score or system matching the SEO industry's broad concept of Topical Authority. What it examines instead is several separate fields and mechanisms relevant to different dimensions of the idea, without assuming those fields definitively measure what their names suggest.

• Writing 100 articles on one topic means you've built authority.

  Not by itself. If those 100 articles add little in the way of Information Gain, in the contextual sense covered earlier, they're not establishing authority just by existing. Whether publishing volume is outpacing quality is something this article treats as a practitioner proxy worth watching, not a documented Google signal.

• The more specialized, the better.

  That's too broad. Specializing in a topic with no demand gets you a very narrow, highly concentrated focus by this article's working definition, and zero traffic from that topic.

• High Topical Focus means a high-quality site.

  No. Topical Focus and Quality are separate concepts here, and one doesn't imply the other.

• A field's name tells you what it does.

  Wrong, and it's the most common analytical mistake in this space. Internal engineering naming conventions aren't official documentation.

• A filed patent means the system got built.

  Not necessarily. At most, it shows that this way of thinking existed somewhere.

• "LSI keywords" need to be in your text.

  "LSI keywords" is SEO jargon, not a concept or keyword category that Latent Semantic Indexing, the actual mathematical technique, ever defined.

• A term used by a third-party tool reflects an actual Google concept.

  Wrong, and this one comes up constantly. Metrics built by commercial tools are proprietary, tool-created metrics. They don't give you direct access to Google's internal fields or scores, and no official equivalence should be assumed. When a tool shows you a "Topical Authority score," that number is something the tool made up, not something it read from Google. Used consistently, those numbers can still work as comparative proxies against competitors. Citing them as if they describe how Google's algorithm actually works doesn't.

• An analyst's interpretation is the same as what the document says.

  Analysis of leaked documentation often includes interpretation layered on top of what's actually documented. Credible analysis distinguishes the two explicitly. Failing to separate them is where a lot of the bad claims in this space come from.

Audit your current Topical Focus

1. Run the script from the measurement section against every indexed URL and generate a Radius list.
2. Cluster your Search Console query data into topical clusters.
3. Build your Publishing Velocity to Quality ratio for the past 12 months.

These three outputs give you a picture of where you stand. Don't make any decisions before you have all three, this is a practitioner recommendation, not a required Google workflow.

Setting a Topic Boundary based on demand and production capacity

Look at three factors together: genuine demand, your team's actual production capacity, and how intense the competition is. A workable Topic Boundary is one where all three are realistic at once. If demand is high but your team can only produce 3 articles a month, narrow the boundary. Narrowing it isn't retreating, it's concentrating your resources where they'll count.

Coverage Gap Prioritization

Once you've listed your gaps, that list is usually longer than what you can actually produce. The order you fill them in shapes where you'll stand 6 months from now. Score each gap against three factors.

Distance from your topical center: a gap sitting close to your core is more aligned with this article's topical framework, and filling it may strengthen the coherence of your modeled topic structure. I'm not claiming it's inherently easier to rank, or that Google rewards proximity to a topical center, this is about internal coherence within the framework this article uses, not a documented ranking mechanism.

Distance from revenue: whether this content connects to a revenue page, or just brings in traffic on its own.

Real production cost: an article that requires an expert interview or original data is expensive. Factor that into your estimate, not just word count.

Deciding what to do with off-topic content

This answers the question I left open in the site-structure section. For every page that shows up on your outlier list, work through this path.

Setting Publishing Velocity to match Quality capacity

Measure your team's actual Quality capacity, not the capacity you wish you had. Then lock your Publishing Velocity to that number. If a manager or client is pushing for volume, show them the pattern from FIG.4 earlier. I want to be precise about what that gives you: the period-based fields covered earlier establish that Google stores certain period-based counts, that's documented context, it doesn't validate this article's specific ratio, the quality-capacity recommendation itself, a Publishing Velocity ranking signal, or the risk model in FIG.4. The recommendation here is my own practitioner framework, presented with that context, not something Google has confirmed.

A periodic review schedule

Review needs a calendar, or it won't happen. The cadence below, and the 12-month window and 20-page sample used throughout this framework, are my own operational defaults, not Google requirements or windows. Twenty pages is simply a manageable review sample, not a threshold.

Final checklist

• Re-run your Topical Focus and Radius list and compare it against the previous period.
• Update your Publishing Velocity to Quality ratio.
• Review categories with fewer than 5 pieces of content, this is a review trigger, not an automatic rule to delete or merge.
• Run 20 newly identified outlier pages through the decision tree.
• Log your largest cluster's share of total impressions.

I'm writing this because any article that claims to cover everything loses its credibility the moment it says so.

What this article gives you: a conceptual map of the subject, a clear separation between what's documented and what's interpretation, a measurement method you can actually run, and a framework for making decisions.

What this article doesn't give you: feedback on your specific project. No article can. Figuring out which of the four patterns from earlier your own site falls into, and what deserves priority, requires looking at your own data, not reading someone else's.

And one more thing no article or course can give you: patience. In my experience, structural and topical work usually needs several months of data before you can judge it fairly, and most of the failures I've seen came from reacting too soon, not from not knowing what to do. That's a pattern I've observed, not a rule that every effect necessarily takes a fixed amount of time to appear.

None of this means Topical Authority is a documented Google score you're working toward. It's a practical umbrella this article uses to hold together several different kinds of evidence, patents that show a way of thinking existed at Google, documented fields and structures whose exact function often isn't established, mechanisms that are documented where the sources actually support that, and my own interpretations connecting some of these pieces together. Those interpretations stay interpretations even where I find them convincing. A patent shows a way of thinking existed somewhere at Google, not that it shipped. A field name is a name, not a function. A proxy built in this article is a way of watching your own trend, not a window into Google's internal number.

What I do think holds up, even if some of the specific connections I've drawn here turn out to be wrong: topical coherence is something you can actually design into a site, and something you can evaluate for yourself using the proxies this article walks through. You decide what a site is about, and you build the structure so that decision is legible, to you and to your own measurements. Authority, in whatever form it actually takes inside Google's systems, isn't something you can declare into existence the same way. A broad site can still do well. A narrow site isn't automatically better. More content isn't automatically stronger. What this article claims is narrower than a ranking guarantee: coherence gives you a clearer, more legible structure to work from within this framework. It doesn't claim Google universally rewards coherent sites, or that an incoherent site is destined to rank worse.

Everything referenced in this article falls into one of these categories. The last category isn't documentation, and it's labeled as such.

• Court documentDocuments and testimony from the DOJ's antitrust case against Google
• Official documentGoogle's own published documentation
• PatentPatent documents and patent families cited throughout this article
• Secondary analysisAnalysis and interpretation, not documentation. Useful for orientation, not for citation as fact

Statements attributed to Google spokespeople should be checked against the original source, with date and platform, before being cited. Quotes appearing in secondary sources aren't primary sources.

Research grounded in primary documentation. Written by Shahram Rahbari