Key takeaways
- Topical authority is a graph of useful pages, not a pile of near-duplicates. One canonical per intent.
- Supporting pages must pass a contribution test. If they restate the hub, merge or retire them.
- Volume is not authority. Update, merge, and unpublish beat publishing another thin post.
The content calendar demanded four posts a month. The site has ninety URLs. Three rank. The rest restate the services page with a new adjective.
Topical authority without thin articles is a graph problem, not a volume problem. You need one canonical page per intent, supporting pages that add evidence the canonical cannot carry, and a merge/update/retire model for everything that fails a contribution test. Publishing a hundred near-duplicates does not build authority. It trains crawlers — and buyers — that your archive is noise.
How to rank your website named the order: intent, technical health, mentions. Content marketing strategies that still work named the smaller channel: useful pages, a path, an ask. This page is how those ideas scale without becoming a content mill.
Authority is coverage with edges, not a pile
Topical authority means a cluster of pages that together answer a subject honestly — with clear hierarchy, internal links that reflect that hierarchy, and facts you will defend. It is not:
- the same service described twelve ways;
- a town name swapped into a template;
- a glossary of definitions anyone could write;
- a blog that exists because Thursday needed a post.
Search systems reward useful coverage. They punish redundant coverage that exists only to catch variants of the same query. Google’s helpful, people-first content guidance asks whether a page substantially adds value. A supporting page that adds nothing substantial is a candidate to merge, not to promote.
| Shape | What it does | Risk |
|---|---|---|
| Canonical hub | Owns the core intent and next step | Becomes stale if never updated |
| Supporting page | Adds evidence, example, tool, or dissent | Drifts into duplicate |
| Thin variant | Same intent, weaker copy | Cannibalises the hub |
| Retired URL | Redirect or unpublish | Temporary ranking fluctuation |
Map the canonical and supporting graph
For each topic you care about, draw one hub and its satellites.
Canonical page: the URL that should win for the primary intent — scope, process, proof, objections, next step. One canonical per intent. If two URLs compete for the same job, pick a winner and demote the loser.
Supporting pages: pages that serve adjacent intents the canonical should not absorb — a worked example, a checklist, a comparison you can defend, a local constraint, original data, or a diagnostic tool. Each supporting page links up to the canonical and receives a link down when the relationship helps the reader.
Forbidden pages: near-duplicates, outdated posts that contradict the hub, and URLs that exist only because a keyword tool suggested them.
Document the graph in a simple table: topic, canonical URL, supporting URLs, last reviewed date, owner. SEO programmes fail when the graph lives only in a consultant’s head.
Friday: pick your highest-value service topic. List every URL that mentions it. Circle one canonical. Mark the rest support, merge, or retire. If you cannot circle one, you do not have authority — you have a pile.
Run the contribution test
Before you publish or keep a supporting page, score it:
1. New intent: does this page serve a query the canonical cannot serve without becoming a book? 2. New evidence: does it add examples, data, process detail, or constraints not on the hub? 3. New object: does it add a tool, table, test, or template the reader can use? 4. New path: does it end with a next step appropriate to this intent?
Pass three of four to publish. Pass two to merge into the canonical as a section. Pass one or zero to retire.
The contribution test is how you avoid thin content without avoiding depth. You are allowed many pages. You are not allowed many pages that say the same thing weaker.
Merge, update, and retire on purpose
Authority compounds when the graph gets sharper over time.
Merge when two URLs serve the same intent. Combine the stronger copy, redirect the weaker URL, and update internal links in the same release.
Update when the canonical is still right but facts aged — pricing bands, regulations, product names, screenshots, process steps. Put a review date on money pages.
Retire when the page failed the contribution test or the business no longer offers the job. Unpublish or redirect to the honest replacement. A quiet 404 forest is worse than a deliberate redirect to the hub.
Do not “refresh” thin posts by adding adjectives. Refresh means new evidence or a narrower intent.
Volume is not authority. A smaller graph of pages buyers finish beats an archive they bounce from.
Link like the graph means it
Internal links should reinforce hierarchy:
- Supporting pages link to their canonical with descriptive anchor text.
- The canonical links down only to supporting pages that help the reader decide.
- Navigation menus are not a sitemap of every post ever written.
Breadcrumbs, hub modules, and related links are editorial choices. They tell crawlers and humans which URL owns the topic.
Pair structural work with mentions outside your site — listings, citations, partnerships — as how to rank your website describes. On-site graph clarity makes off-site mentions land on the right URL.
Read Google Search Central — Consolidate duplicate URLs when merges and redirects are part of the plan.
What you can do alone
You can map the graph, run the contribution test on live URLs, merge duplicates, set review dates on canonicals, and unpublish posts that restate the homepage. You can stop the calendar until the hub is worth supporting.
What often needs help: rewriting the canonical so it holds the offer, building supporting pages with real objects, redirects and internal link passes without breaking forms, and a sustainable SEO content programme that publishes fewer pages on purpose.
SEO is the ongoing owner when the graph is the strategy — not another thirty-day post streak. The estimator at get started scopes whether you need new pages, merges, or a canonical rewrite first.
