Written 19 May 2026. Most of what I'm describing here I learned the hard way on a mid-size B2B media brand between September 2025 and February 2026. Some of it I'm still living with.
The Trinity and Why It Made Sense
Section/Topic/Tag became the default IA for media sites because it solved a real problem cleanly. Editorial teams think in sections — the org chart of a newsroom maps naturally to top-level site sections. Readers navigate by topic when they want depth on a subject. Tags provided the long tail: a way to aggregate content that didn't fit neatly into either of the first two layers.
The structure also made algorithmic sense for Google circa 2013–2019. Aggregation pages with many articles pointing at them accumulated internal link equity. Topical depth signals — lots of articles tagged "climate policy" pointing to a Climate Policy topic page — helped Google understand what a site was authoritative about. Tag pages indexed well because they had content (article headlines, excerpts) and signals (links from every article using that tag).
For roughly a decade, the trinity delivered. Traffic to topic and tag pages was real. The structural logic held.
I built media site IA on this model for years. I recommended it. I defended it in client workshops in 2022 when some people were starting to question it. I was wrong to defend it that late.
What Killed It: Three Simultaneous Shifts
No single change killed the trinity. Three things landed close enough together that the cumulative effect was decisive.
Shift one: HCU and the thin-content reckoning. Google's Helpful Content system, which matured through 2024, penalizes pages that exist primarily to aggregate content rather than to answer questions. Tag pages are definitionally aggregation pages. Most topic pages, as implemented by media CMSes, are too. The HCU didn't target the trinity explicitly — but it removed the protective halo that "we're a real publisher" used to provide.
Shift two: AI Overviews eating informational query traffic. The queries that drove meaningful traffic to topic pages — "what is [term]", "overview of [subject]", "[subject] explained" — are now heavily AI-Overview territory. Google answers them at the top of the page. Click-through to the topic page drops 40–70% for these query types. The aggregation layer of the trinity was already being eroded; AI Overviews accelerated the erosion to near-collapse for many sites.
Shift three: crawl budget contraction. As Google's crawl behavior shifts toward prioritizing entity-graph-relevant pages, the crawl cost of maintaining 40,000 tag pages on a site with 80,000 articles becomes unjustifiable. I pulled log data from the B2B media client in October 2025. Tag pages were receiving 23% of all Googlebot crawl requests. They were generating 1.3% of organic traffic. The ratio is not sustainable.
How the Trinity Actively Damages You Now
Crawl Dilution at Scale
A media site that publishes 20 articles per day and has operated for 8 years has roughly 58,000 articles. If each article carries an average of 7 tags, that's 406,000 tag-article relationships. Most CMS platforms create a unique paginated tag archive for each tag. Even with aggressive canonicalization of paginated pages beyond page 1, you end up with thousands of crawlable tag index pages.
The crawl math is brutal. If Googlebot has a crawl budget of 10,000 requests per day (reasonable for a site of this size), and 23% goes to tag pages that drive 1.3% of traffic, you are burning 2,300 daily crawl requests on pages that collectively earn you 130 visits a day. That's 17.7 crawl requests per daily visit sourced from tags. Meanwhile, article pages — which drive 71% of traffic — may be getting crawled once per week for content updates.
The fix is not to add crawl budget. The fix is to stop wasting the crawl budget you have on pages that don't earn their keep.
Entity Confusion in the Knowledge Graph
This one is subtler and took me longer to articulate.
When a media site has both a Topic page for "Climate Policy" and 47 tags including "climate policy," "climate-policy," "climate legislation," "carbon policy," "green policy," and "environmental regulation," the entity graph sees multiple pages competing to represent the same entity. Google has to make a decision about which page is the canonical entity representative for your site. Usually it picks wrong — often a tag page that accumulated links rather than a topic page that was editorially maintained.
The result is that when Google builds its entity graph and decides which sources to cite for climate policy queries, your site's entity signal is fragmented across a dozen pages instead of concentrated on one. You lose citations to sources with cleaner entity structures. I've watched this happen across three media clients since 2024.
Thin Aggregation Pages and AI Overview Blindness
AI Overview citations from media sites go overwhelmingly to individual articles — specifically, articles with bylined expert authors, clear publication dates, and substantive original reporting. They go to topic/tag aggregation pages almost never.
This isn't a technical penalty. It's a quality signal. An aggregation page says: "here is a list of content about X." An article says: "here is what I know about X, with evidence." The AI extraction layer prefers the latter by a wide margin. The trinity's reliance on aggregation pages as a structural layer is therefore misaligned with where AI Overview value actually comes from.
What I Replace It With: The EAT-Node Model
I call it the EAT-Node model — Entity, Authority, Temporal. It's not a clever acronym; it describes three types of pages that actually earn their place in a 2026 media site IA.
Entity Hubs
Entity Hubs replace both topic pages and most tags. An Entity Hub is a curated, editorially maintained page tied to a single recognized Knowledge Graph entity. It has:
- Original editorial content: a 500–900 word overview written (or reviewed) by a named expert on staff, not auto-generated from article aggregation
- Structured data with
sameAslinking to the Wikidata or Wikipedia entry for the entity - A controlled, manually curated list of related articles — not an auto-feed from tag matching
- A clear update policy: the editorial content is reviewed quarterly, not left to decay
The critical difference from topic pages: Entity Hubs are not created on demand. A journalist covering a new company doesn't automatically trigger a tag or topic page. Entity Hubs are created deliberately, approved editorially, and given resources to maintain. The B2B media client had 3,200 auto-generated topic pages. We replaced them with 47 Entity Hubs. 47. The rest: either redirected to the most relevant Entity Hub, or noindexed and allowed to 410 over time.
Example JSON-LD for an Entity Hub:
{
"@context": "https://schema.org",
"@type": "WebPage",
"name": "Carbon Policy — In-Depth Coverage",
"about": {
"@type": "Thing",
"name": "Carbon Policy",
"sameAs": [
"https://www.wikidata.org/wiki/Q123456",
"https://en.wikipedia.org/wiki/Carbon_policy"
]
},
"author": {
"@type": "Person",
"name": "Jane Researcher",
"jobTitle": "Senior Policy Correspondent"
},
"dateModified": "2026-04-15"
}Authority Signals at the Author Layer
This isn't strictly an IA decision, but it's inseparable from IA in 2026: author pages need to function as entity nodes, not as byline archives. An author page that just lists articles does almost nothing for entity-graph alignment or AI Overview citation rates. An author page that declares the author's expertise domain, links to external authority signals (LinkedIn, institutional affiliations, published research), and includes structured Person schema with knowsAbout properties — that page is an entity node that strengthens every article it's connected to.
I restructured author pages for the B2B client in November 2025. We went from generic byline archive pages to entity-rich author profiles with an average of 340 words of credentials, expertise areas as structured data, and external authority links. Within 8 weeks, 3 author pages appeared in AI Overview citations for queries in their domain areas. The articles themselves hadn't changed.
Temporal Nodes Instead of Tag Sprawl
The one aggregation type that still works in 2026: time-bounded collections with editorial framing. "Coverage of the Q1 2026 EU carbon price negotiations" is a useful aggregation node because it is bounded, specific, and answers a real question a reader has. It's not a tag that auto-populates forever.
Temporal nodes in the EAT-Node model:
# Structure
/[section]/[entity-slug]/[year-or-event]/
# Examples
/policy/carbon-pricing/eu-q1-2026-negotiations/
/technology/chip-supply-chain/2025-taiwan-disruption/
/finance/fed-rate-decisions/2026/These pages are created by editorial decision, maintained through the event lifecycle, and then either kept as historical records with clear date framing or redirected to a broader Entity Hub once the event has concluded. They do not auto-generate. They do not proliferate via tag assignment.
How to Migrate Without Losing Traffic
The migration from trinity to EAT-Node is the part that scares teams most, and reasonably so. Tag pages, despite their problems, do hold some traffic. The migration has to be staged.
My sequencing:
- Audit first. Pull all tag/topic pages from your sitemap. Join with GSC clicks for the last 12 months. Segment into four buckets: 0 clicks, 1–20 clicks, 21–200 clicks, 200+ clicks.
- The zero-click bucket: noindex immediately, no redirect needed. These pages are costing you crawl budget and providing nothing. The content pruning framework applies directly here.
- The 1–20 click bucket: 301 redirect each to the most relevant Entity Hub, once that Entity Hub exists. If no relevant Hub exists yet, noindex and put on the list for Hub creation evaluation.
- The 21–200 click bucket: this is where you need to be careful. Some of these pages hold actual traffic from niche queries. Analyze the queries driving the traffic. If the traffic is coming from queries that your planned Entity Hub would also serve, migrate with redirect. If the queries are specific enough that they need their own page, consider whether this tag should become an Entity Hub.
- The 200+ click bucket: treat each page individually. These are your edge cases. Some may be Entity Hub candidates. Some may be driving traffic from a query type that's about to be AI-Overviewed into obsolescence — in which case, migrate them and don't mourn the traffic.
Timeline: for the B2B client, the full migration took 4 months from audit to completion. We did it in phases, section by section, rather than all at once. We lost 8% of organic traffic in month 1 (from noindexed zero-click tag pages that had accumulated some PageRank). We gained 23% over the following 3 months as Entity Hub pages established authority and began earning AI Overview citations. Net result at month 4: +14% organic traffic on 40% fewer indexed pages.
Where I Disagree With the Current Consensus
The current consensus in technical SEO circles is that topic clusters with pillar pages are the replacement for the trinity. I disagree, specifically for media sites.
Topic clusters — as typically implemented — reproduce the same problem at a different level. A pillar page that aggregates cluster content is still an aggregation page. It still doesn't answer questions. It still can't earn AI Overview citations. The pillar page model works reasonably well for SaaS content marketing because those sites start with thin content and need a structure to organize around. Media sites don't have thin content — they have enormous archives of original reporting that is being strangled by bad aggregation infrastructure. The fix isn't to add better aggregation infrastructure on top. The fix is to reduce aggregation and strengthen entity signals.
My second contrarian position: section pages are underrated, not over-relied-upon. The dominant advice right now is to flatten navigation hierarchies and reduce the role of section pages. I think this is wrong for media sites. Section pages, when they have editorial identity — an editor's note, a stated coverage philosophy, a team bio — function well as entity nodes. "The Finance Section of [Publication]" is an entity. It has authority signals. It earns citations. Don't flatten it; upgrade it.
Numbers from the B2B Media Project
I'm including these with the caveat that one site's data is not a sample. But the magnitudes are worth sharing.
- Tag pages before migration: 3,847
- Tag pages noindexed in phase 1 (zero traffic): 2,914
- Tag pages redirected to Entity Hubs: 714
- Tag pages converted to Entity Hubs: 47
- Remaining unconverted tag pages (ongoing): 172
- Googlebot crawl on tag-type pages, before: 23% of total crawl
- Googlebot crawl on tag-type pages, after 90 days: 4% of total crawl
- Crawl frequency increase on article pages: +31%
- AI Overview citations (tracked via GSC "AI Overviews" filter): +67 appearances over 90 days
- Organic traffic change, 6 months post-migration: +14% vs. prior 6-month period
The 67 new AI Overview appearances were the metric that mattered most to the editorial leadership. Organic traffic is nice; being cited by Google's AI as a source is a different kind of authority signal, and the team noticed.
For context on the AI Overview traffic dynamics, my AI Overviews CTR piece has baseline CTR data by query type. For the HCU recovery framework that informed the phased migration approach, the HCU deep dive is directly applicable.
What Stays: Sections Are Not the Problem
I want to be precise about what I'm arguing, because the natural reaction to "the trinity is harmful" is to propose tearing down all structure.
Sections stay. A media site organized by editorial section — with section pages that have genuine editorial identity and are maintained as entity nodes — is still sound IA. The section layer is not what's broken. What's broken is the assumption that topic and tag layers below the section are providing value that justifies their crawl and maintenance cost.
In the EAT-Node model, the structure is:
Section (entity-grade page with editorial identity)
└── Entity Hub (curated, maintained, structured data)
└── Individual Articles (bylined, dated, expert-authored)
└── Temporal Nodes (event-bounded, created by editorial decision)There's no tag layer. There's no auto-generated topic layer. Every page in the IA is either an entity node or an article. If it's neither, it probably shouldn't be indexed.
External reference worth reading: the Reuters Institute's 2026 Journalism and Media Technology report has a section on search traffic dependency that's sobering context for why the IA decisions I'm describing are urgent, not optional.
The Uncomfortable Takeaway
The trinity didn't fail because it was badly designed. It failed because the conditions it was designed for no longer exist. Google doesn't need your tag pages to understand topical breadth — it has its own entity graph. Readers don't need your topic pages to find more content on a subject — AI answers their follow-up questions. The aggregation layer of media site IA served Google and served readers. Now it serves neither.
What remains valuable is exactly what was always hardest to produce: original expert reporting tied to real entities, by named humans with demonstrable credentials, maintained and updated over time. The IA implications of that aren't complicated. They are expensive. The structural decisions described here don't make the content problem easier. They clear away the structural debris so the content that is good can actually get found.
That's the work. Most of it isn't in the sitemap.
Filed under: media SEO, information architecture, AI Overviews, entity graph, EAT-Node model. Data current as of May 2026.
