Topical authority here means one specific thing: the strength, completeness and consistency of your site's information about a subject area, as computed by us and explainable by us. It is not a Google metric. It is not a third-party vendor score. It is an analysis of your own corpus, and every part of it can be traced to the documents that produced it.
The analysis runs on your server
No content leaves the install. The topic engine is lexical, not embedding-based, and it runs entirely inside PHP against the corpus the content scan already extracted. There is no API key, no outbound request, and no model involved in this part of the product.
That was a deliberate trade. Embeddings would cluster better on some sites, and sending a whole corpus to a provider is a privacy decision that has not been taken. Until it is, the shipped engine is the one that can run on a site with confidential drafts, client work or member-only content without anyone having to think about it.
How the clustering works
The method is documented in full in the methodology, and the summary is short enough to state here honestly.
Boilerplate is removed first. Navigation, headers, footers, sidebars, forms, scripts and SVG are stripped before any text analysis. Untreated boilerplate dominates lexical similarity and produces "clusters" that are really just the theme template.
Documents are vectorised with TF-IDF. Sub-linear term frequency, smoothed inverse document frequency. Title tokens are weighted more heavily than body tokens, and taxonomy tokens more heavily than body tokens too, on the basis that both are human-authored subject signals rather than incidental vocabulary.
Site-wide terms are dropped. Any term appearing in more than half the documents is treated as boilerplate and discarded. This adapts to your site instead of assuming a language or shipping a fixed stoplist that fails on a non-English corpus.
Clustering is by threshold, not by a fixed k. Single-link agglomeration over cosine similarity. The number of topics a site covers is not known in advance, and forcing a k produces arbitrary groupings that look authoritative and are not. Documents that resemble nothing else stay unclustered, which is itself informative — that is usually where the orphans and the one-off pages are.
Labels prefer human authorship. Where at least 60% of a cluster shares a taxonomy term, that term becomes the label. Otherwise the label is derived from the most distinctive terms in the cluster. Derived labels can be wrong, and the interface says so rather than presenting a generated string as a fact about your site.
Pillar candidates, not pillar pages
For each cluster the engine ranks members as pillar candidates using three inputs: normalised inbound internal links, relevance to the cluster centroid, and normalised word count — weighted in that order of importance.
Length is deliberately the smallest term. A 4,000-word post that nothing links to and that sits at the edge of its own cluster is not the pillar; it is a long page. Inbound links carry the most weight because they are the clearest evidence that the site's own authors already treat a document as the reference for its subject.
The output is a candidate list with the contributing numbers beside it, not an instruction. Choosing the pillar is an editorial decision, and the person who knows which page is commercially load-bearing is you.
Coverage and connectivity bands
Two bands are reported per cluster, and both are summaries of counts rather than quality judgements.
Coverage is document count: strong at eight or more documents, moderate at four or more, thin below that. A thin cluster means you have written a few things about a subject, not that they are bad.
Connectivity is the mean number of inbound internal links per cluster member: strong at three or more, moderate at one or more, weak below that. A cluster with strong coverage and weak connectivity is the common and fixable case — twelve good articles that no one, including your own site, points at.
Bands exist because a percentage would be worse. There is no composite 0–100 topical authority score anywhere in this product, because a percentage a user cannot decompose is not explainable, and an unexplainable number is not shippable.
Orphans and internal-link opportunities
Two outputs come out of the same graph.
Orphan content is documents with no inbound internal links from the rest of the site. These are usually not deliberate — they are posts published before a category existed, migrated pages, or articles whose natural parent was written afterwards and never updated.
Internal-link opportunities are pairs of documents in the same cluster where one has high centroid relevance and no link between them exists. The suggestion names both documents and the cluster that connected them, so you can see why it was proposed and reject it when the two pages are genuinely about different things.
Nothing is applied automatically. Internal linking changes site-visible output, so it goes through the same rule as everything else here: the plugin proposes, you dispose, and the change is recorded.
The 600-document ceiling
Above 600 documents the topic engine returns no clusters at all, and records in the activity log why. It does not return a partial result.
The reason is memory rather than arithmetic. Clustering compares every document against every other, which grows quadratically, but the binding constraint turned out to be the vectoriser: its term-frequency map alone measures roughly 97 MB at 1,500 documents, before the document text, the link map and the vectors that are all live at the same moment. Against a typical PHP memory limit that fails somewhere near 700 to 900 documents, so a 1,500 ceiling was one the engine could never actually reach. The ceiling is checked before the corpus is loaded rather than after, because a limit tested afterwards would only trigger once the memory had already been spent.
This is stated plainly rather than discovered later. If your site is larger than that, this feature does not work for you yet, and lifting the cap needs the pairwise pass replaced with inverted-index blocking rather than a configuration change. Every other part of SiteRank AI — the SEO audit, the GEO audit, crawler inspection, structured-data inspection — runs over the full corpus regardless of size, in batched, resumable background jobs.
Where this sits on the evidence scale
Topic clusters, pillar pages and internal linking are long-standing information-architecture practice with a plausible and well-understood mechanism: they make a site easier to crawl, easier to navigate and easier to retrieve from. Internal linking's effect on crawl discovery and on how a page is described is ESTABLISHED STANDARD territory in conventional SEO.
The claim that a well-structured cluster improves how often an AI answer engine cites you is not. It is at best EMERGING PRACTICE, it is not confirmed by any provider, and this product does not present it as a ranking factor. Google's position on its own AI features is that no special optimisation is required beyond normal SEO, and nothing here contradicts that.
What the analysis gives you is a defensible map of your own coverage — which is worth having on its own terms, whatever the retrieval systems do next.
Related reading
Frequently asked questions
My site is larger than the document ceiling. Is any of this usable?
The clustering is not, and the product says so rather than handing you a partial map. Everything else works at any size: the technical SEO audit, the GEO audit, crawler inspection and structured-data inspection all run over the full corpus in batched, resumable background jobs. Lifting the ceiling is an engineering change to how documents are compared, not a setting you can raise, so treat the clustering as unavailable on a large site until that work is done.
Should I delete or merge my thin clusters?
That is an editorial decision, and the band is not an argument for either. Thin means you have written a few documents on a subject; it says nothing about whether they are good, whether they convert, or whether the subject deserves more. The more common and more fixable finding is a cluster with strong coverage and weak connectivity — material that exists and that nothing on your own site points at.
Do I need to apply every internal-link suggestion?
No, and you should expect to reject some of them. A suggestion is a pair of documents in the same cluster with high centroid relevance and no link between them, which is a reason to look rather than a conclusion. The suggestion names both documents and the cluster that connected them so you can judge it, and nothing is written to your site until you act.
If I restructure my site around these clusters, will AI answer engines cite me more often?
Nobody can tell you that, and this product does not imply it. The conventional benefits are well understood — a clearly structured site is easier to crawl, easier to navigate and easier to retrieve a relevant passage from — but the specific claim that cluster structure changes how often an answer engine attributes you is unconfirmed by any provider and sits no higher than EMERGING PRACTICE. If you want to know what is actually happening, that is a measurement rather than an inference, and it lives in citation monitoring.