TechCrunch's Entity Registry Still Grows, But Hollowed Out

Corrections, 10 September 2026. This article has been corrected twice on the day of publication, and both errors came from trusting the slice of a dataset that was easiest to query.

First, the original version measured category and post_tag without querying /wp-json/wp/v2/taxonomies, where TechCrunch exposes a 45,138-term Crunchbase-linked entity taxonomy. It missed the custom entity layer entirely.

Second, the first correction treated the first three taxonomy pages as evidence that the registry had stopped around 2014. That was also wrong: orderby is silently ignored on this install, so pagination returns terms in term_id order — oldest first. Re-sampled across the full page range, records run through 2024. What changed is not whether records are created but what they contain, which is the finding this version reports.

TechCrunch has a Crunchbase-linked entity layer. Its 45,138 crunchbase_tag terms include companies, people, and products. Older organization records carry a Crunchbase URL and a homepage URL — exactly the resolvable identifiers a machine needs to know that a document is about a specific firm.

It is still creating records today. It stopped putting the identifiers in them.

Anthropic has no record in it at all. OpenAI has one, created in February 2016, attached to 10 posts — against 1,420 posts under the free-text tag openai. The entire generative-AI era of TechCrunch's coverage happened outside the structured system that was built to describe companies.

The framework nobody looks for

The reason this is not common knowledge is that you have to ask the right endpoint. WordPress exposes a site's registered taxonomies at /wp-json/wp/v2/taxonomies, and almost nobody queries it — they go straight to categories and tags, which are the two that exist on every WordPress install by default.

On 10 September 2026, https://techcrunch.com/wp-json/wp/v2/taxonomies returned eighteen taxonomies. Two custom namespaces matter for entity classification:

Taxonomy	REST base	Terms	What it holds
_tc_cb_tag_taxonomy	crunchbase_tag	45,138	Crunchbase-linked company, person and product entity terms; older organization records carry Crunchbase and homepage URLs
tc_industry	tc_industry	136	A controlled industry vocabulary attached to tc_battlefield, not to editorial posts

The crunchbase_tag records are the interesting ones. Slugs follow a strict pattern — <name>-organization, <name>-person, <name>-product — and each term's description field is not prose. It is base64-encoded JSON. Decode the record for openai-organization and you get:

{
  "name": "OpenAI",
  "crunchbase_url": "https://www.crunchbase.com/organization/openai",
  "homepage_url": "https://www.openai.com/",
  "created_at": 1454302545
}

That is a genuine entity record. A stable external identifier, a canonical homepage, and a creation timestamp — 1 February 2016. This is the thing the earned-media industry assumes it is buying when it buys a placement: a durable, machine-readable link between authoritative coverage and a specific, resolvable entity.

That is what a record created in 2016 looks like. A record created in 2024 is usually an empty shell.

The registry still grows. Its records stopped being useful.

The obvious question is when this stopped working, and the obvious query gives the wrong answer — which is worth stating plainly, because it is the trap that produced this article's second correction.

Paginating a WordPress taxonomy returns terms in term_id order, oldest first, and orderby is silently ignored on this install. Read the creation dates on the first few pages and you will conclude the registry died in 2014. It did not; you sampled its oldest records. Sampled properly across the full range of 452 pages, 669 records carrying a timestamp are distributed across every year from 2007 to 2024.

The decay is not in the count. It is in the contents. Grouping those same records by the era they were created in:

Records created	Sampled	Carry a Crunchbase URL	Attached to ≥1 post	Company records (vs. people)
2007–2013	309	100%	82%	66%
2014–2019	213	100%	72%	83%
2020–2024	147	12%	3%	12%

Every record created before 2020 carries the external identifier that makes it resolvable. Barely one in eight created since does. And where the old records were attached to real coverage — 82% and 72% of them point at at least one article — the modern ones are almost entirely orphaned, at 3%.

The newest page of the taxonomy makes it concrete. Of its 38 terms, 37 carry 2024 creation dates and one has no timestamp; every one is a -person record, every one has a count of zero, and not one carries a Crunchbase URL. The first three are marina-temkin-person, jake-cohen-person, and helen-toner-person. The system is still writing rows. It is no longer reliably writing resolvable organization records.

That is a more awkward failure than abandonment. An abandoned registry announces itself — you check the dates and stop trusting it. A registry that keeps growing while its records quietly stop carrying identifiers looks maintained from the outside, and only a field-level audit reveals that the thing being maintained is no longer the thing you need.

You can see the consequences in the records themselves. The largest term in the taxonomy is twitter-company, with 3,231 posts — a company that has not been called Twitter since 2023. tesla-motors-organization holds 560 posts under a name the company dropped in 2017. The registry is a well-formed snapshot of the startup world as it looked more than a decade ago.

Now compare the structured record against the free-text tag for the companies that matter most in 2026:

Company	crunchbase_tag (structured)	post_tag (free text)
Anthropic	absent	489
OpenAI	10	1,420
Nvidia	285	858
Stripe	90	386
Tesla (tesla-motors)	560	0

Anthropic — one of the most-covered companies in technology — has no structured entity record on TechCrunch at all. Its 489 articles exist only as a string. OpenAI's structured record captures 10 of its 1,420 articles, or roughly 0.7% of its coverage.

The last row is the clearest picture of the split. tesla-motors has 560 posts in the structured system and zero in the tag namespace; the newsroom moved on to a different string, and the entity registry kept the old one. Two parallel systems, neither aware of the other, and the one with the resolvable identifiers is the one that no longer tracks current coverage reliably.

This is not unique to TechCrunch, and the second pattern is worse

Fortune runs a different architecture and arrives at a similar place. Companies there are not a taxonomy but a custom post type: https://fortune.com/wp-json/wp/v2/company returns 2,545 entries, each a real page at fortune.com/company/<slug>.

Search that registry and the logic becomes clear:

Query	Records in Fortune's company registry
apple	1
nvidia	1
stripe	1
openai	0
anthropic	0
zzzznotreal (control)	0

OpenAI and Anthropic are absent from the structured company registry of the most famous business publication in the world. Not under-covered — absent. Fortune's registry tracks the Fortune 500 and adjacent corporate stature, so membership is an eligibility judgement, not a coverage record. A company can be written about constantly and never enter it.

So there are two distinct failure regimes, and neither is the one the market worries about:

1. Hollowed registry (TechCrunch). The entity layer was built properly and still grows, but its records stopped carrying external identifiers around 2020 and are now almost never attached to coverage. It looks maintained; it no longer resolves anything.
2. Eligibility registry, not coverage registry (Fortune). The entity layer is maintained, but membership tracks corporate stature rather than editorial attention, so the most-covered companies in a new category can be missing entirely.

In both cases the publication's machine-readable statement about who you are has come apart from the publication's actual coverage of you. The placement and the record are no longer the same transaction.

What the newsroom actually uses

With the entity layer no longer attaching recent records to coverage, TechCrunch's live company metadata mostly falls back to the ordinary tag namespace — and it is enormous. The API reports 125,092 entries in post_tag against 262,184 posts: one tag for every 2.1 posts ever published, accumulated by hundreds of reporters since the site launched in 2005, with no visible merge step behind it.

The editorial categories are no help either. There are 25, every one with parent: 0 — no hierarchy, no sub-industry, no rule. One of the 25 is called Category Functionality, slug ben-test-2, with 2 posts: a test category sitting in production taxonomy long enough to have acquired content.

Category	Posts
Hardware	67,676
TC	60,295
Media & Entertainment	55,324
Startups	53,430
AI	15,645
Enterprise	13,765
Venture	11,658
Transportation	11,089
Biotech & Health	6,949
Fintech	6,897
Security	6,726
Apps	6,420
Climate	3,463
Space	3,316
Social	3,231
Fundraising	2,862
Crypto	2,783
Privacy	2,602
Government & Policy	2,331
Commerce	1,305
Gadgets	1,195
Robotics	765
Gaming	736
Real estate	34
Category Functionality (ben-test-2)	2

Read that as a list of beats, because that is what it is. The Startups category page describes itself as covering "climate, crypto, fintech, SaaS, transportation, and consumer tech" — five of which are separate top-level categories in the same list. These are desk assignments that overlap by design, not classes that partition anything.

In the tag namespace, distinctiveness does most of the work

The free-text namespace can still create a strong anchor, but not because fame magically fixes metadata. Inside TechCrunch's post_tag namespace, the driver is name distinctiveness: near-unique strings concentrate; short names and names embedded inside other entities fragment. We measured it by summing every tag containing a company name and checking what share the canonical tag holds:

Company	Matching tags	Total taggings	Canonical tag share
Anthropic	12	503	97% (anthropic, 489)
Waymo	7	690	93% (waymo, 643)
OpenAI	42	1,528	93% (openai, 1,420)
Nvidia	42	940	91% (nvidia, 858)
Stripe	17	451	86% (stripe, 386)

Ninety-plus percent concentration is a strong anchor. A retrieval system crawling TechCrunch for OpenAI finds 1,420 documents under one consistent string, and the residue — openai-devday, openai-lawsuit, azure-openai-service — clearly belongs to the parent.

Now run the same measurement on companies that are real, funded, and covered, but whose names collide more easily with other tags.

Company	Canonical tag count	What competes with it
Ramp	79, 74% share	alex-rampell, liveramp, fedramp, workramp
Deel	50, 82% share	ideeli (9), deel-io, deelio
Mercury	27	mercury-fund (10), mercury-solar-systems, dfj-mercury
Vanta	6, 12% share	complyadvantage (7), vantage-robotics (5)
Clay	4, 4% share	barclays (38), clayton-christensen (7), clay-bavor (5)
Linear	4	linear-technology, non-linear-editing, linearb

Vanta's own tag is smaller than the tag for a competitor that happened to match the search string. Clay's company tag holds four posts inside a namespace where "clay" mostly means Barclays, Clayton Christensen, or a former Google VP named Clay Bavor.

The anchor is bimodal, not continuous, but the split is not fame. Ramp and Deel are not household names, and both hold strong canonical shares. Vanta and Clay collapse because their names are substrings or homonyms inside the same namespace. Distinctiveness governs canonical share inside post_tag; prominence governs whether a separate curated registry bothers to mint a record at all. The structured system that would have resolved the ambiguity stopped attaching recent organization records to coverage years ago.

That is not a coverage problem. Vanta, Clay, and Linear have all been covered. It is an entity resolution problem: the coverage exists, and the machine-readable link between the coverage and the company does not hold.

Why this matters more in 2026 than it did in 2016

For a human, none of this is visible. You read the article, you see the company, you move on. Tag pages are navigation furniture.

For a machine, the tag is the relationship. When an AI engine treats TechCrunch as an authoritative source about a technology category — and they do — it is retrieving passages, resolving named entities, and deciding which documents belong to which company. A publication's own structured metadata is the cheapest, highest-confidence signal available for that last step.

The cruel detail is that TechCrunch built exactly the right thing for this. A Crunchbase-linked record with a homepage URL is a near-perfect entity anchor; an engine could resolve against it with high confidence. Older records show the system once did that work. Newer rows show a different maintenance state: records still get created, but recent ones rarely carry identifiers or attach to articles. The infrastructure that would make modern coverage machine-resolvable exists, but its recent company coverage is hollow.

So the inheritance runs like this. A strong canonical tag means an engine can assemble twenty documents about you into one coherent entity. A weak one means your six mentions get resolved against a homonym, split across three near-duplicate strings, or dropped for lack of confidence. Same publication, same reporters, same editorial standard — completely different machine-readable outcome.

This is the part the earned-media industry still gets wrong. The placement is treated as the deliverable. The placement is an input. What determines whether a placement compounds into machine-visible authority is whether the machine can attach it to you unambiguously, and that depends on infrastructure neither the PR agency nor the publication is maintaining as a reliable current-company record.

What a maintained system looks like, for contrast

GICS, the classification standard behind most global equity indices, assigns every company exactly one code in a four-level hierarchy, maintained by a committee with published revision rules. The Legal Entity Identifier gives each legal entity a globally unique 20-character code precisely so machines never have to guess whether two records describe the same firm. Crunchbase itself sits in the middle: a real company record with a stable identifier, but with industry categories contributed by founders, investors, and staff rather than assigned by rule — which is why researchers who wanted an unbiased startup taxonomy derived 38 classes from company descriptions with topic modeling instead of using the 46 categories the database already carried.

Those systems share three properties: a stable identifier per entity, a rule for assigning classes, and someone whose job it is to keep the record useful. TechCrunch's entity taxonomy still has legacy identifiers. Its tc_industry vocabulary shows a separate class layer, but it is not attached to editorial posts. The missing piece is current, usable maintenance: when new rows stop carrying identifiers or attaching to coverage, even a real entity layer stops describing the live market.

Schema is not the same as maintenance. A publication's machine-readability is a property of both, and only one of them is visible from the outside without checking timestamps.

Checking any publication's entity layer

Anyone can run this, unauthenticated, on any WordPress publication. The order matters — this is the sequence whose absence produced the error at the top of this article.

1. Enumerate the taxonomies before assuming which one matters.

https://PUBLICATION/wp-json/wp/v2/taxonomies

Read every entry, not just categories and tags. Custom taxonomies are where entity layers live, and they are named unpredictably. Also check /wp-json/wp/v2/types — Fortune's company registry is a post type, not a taxonomy, and would be invisible to a taxonomy-only sweep.

2. Size each candidate namespace.

https://PUBLICATION/wp-json/wp/v2/<rest_base>?per_page=1

Read the X-WP-Total response header. A namespace with tens of thousands of terms is a real system; one with a few dozen is vestigial.

3. Look for a record for your company, and read its description.

Some publications store structured JSON there, base64-encoded or plain. If it carries external identifiers — a Crunchbase URL, a homepage, a stock ticker — you have found a genuine entity layer rather than a label.

4. Date the layer and audit the fields. If records carry a creation timestamp, sample across the full page range and plot the years. Then check whether newer records still carry the identifiers and article counts that made older records useful. A registry can keep growing while the records hollow out.

5. Prove query parameters with controls before trusting them. This is the trap that will otherwise produce a confident wrong answer. On this install, orderby=count against crunchbase_tag is silently ignored, and custom-taxonomy filters against /wp/v2/posts can also return the unfiltered newest posts. We confirmed the filter failure with a control: a real crunchbase_tag id and crunchbase_tag=999999999 returned the identical five newest post IDs. A bogus-identifier or alternate-order control is a one-request test, and it should run before any claim derived from ordering or attachment.

The endpoint paths are common across WordPress sites, which are most of the web that runs a known CMS, but the meaningful namespace names and parameter behavior are not. Enumerate first; control the query; measure second.

What to do about it

You cannot fix TechCrunch's taxonomy. You are not going to get 125,092 tags merged, and you cannot pitch your way into an entity registry whose recent records carry no identifiers and point at no articles. That is the practical finding, and the correction only sharpens it: the problem is not that the publication never built the system. It is that the system exists, looks authoritative, and will not include you.

Own the entity definition where machines read it first. Your own site is the only surface where you control structured identity completely. A schema.org Organization record, marked up the way Google's structured data documentation specifies, on a stable canonical URL, with explicit sameAs links to the identifiers that already exist for you. When a publication's tag is ambiguous, the engine falls back to whichever source is unambiguous. Make that source be you.

Claim the identifiers that machines already reconcile against. A Wikidata item — TechCrunch's own is Q1022366 — is the join key that a large share of entity-resolution pipelines use, directly or through derivatives like DBpedia. Research institutions have ROR, legal entities have LEI, and the W3C Organization Ontology exists specifically to express organizational structure in a form a machine can traverse. Being present in those graphs is what converts a name into an entity. Note what TechCrunch's own records point at: Crunchbase. Publications that build entity layers reconcile against public identifier graphs, so being present in those graphs is what makes you eligible to be recorded well when someone does maintain a registry.

Use one name, everywhere, without variation. Every string variant you tolerate — legal entity versus product name, with and without "Inc.", the old name you rebranded from — is another node an engine has to reconcile. tesla-motors-organization is what happens when a name changes and the records do not.

Audit the entity layer before you value the placement. Two publications with identical readership can differ completely in whether coverage becomes a machine-readable record. That is now measurable in five requests, before you pitch, and it belongs in the same conversation as domain authority and audience fit.

The general principle

Every source an AI engine trusts has an internal data model, and that model was almost never designed for machine consumption — or was designed for it once, by someone who has since left.

The market buys placements. The machine inherits records. Those were the same transaction when publications maintained their entity layers, and they have quietly come apart.

Machine Relations starts from that fact instead of wishing it away. The publication is not going to retrofit identifiers onto a registry whose recent rows are mostly hollow. Your job is to be the well-formed record that its ambiguity resolves against.

---

Method note. All figures were retrieved from public WordPress REST APIs on 10 September 2026, unauthenticated, and TechCrunch totals were rechecked at 12:24 UTC. TechCrunch: /wp-json/wp/v2/taxonomies (18 taxonomies), _tc_cb_tag_taxonomy with REST base crunchbase_tag (X-WP-Total: 45138), tc_industry (X-WP-Total: 136), /wp-json/wp/v2/categories (25 records), /wp-json/wp/v2/tags (X-WP-Total: 125092), /wp-json/wp/v2/posts (X-WP-Total: 262184). Fortune: /wp-json/wp/v2/company (X-WP-Total: 2545), with registry membership tested via the search parameter and validated by a bogus-query control. Per-company tag figures sum the count field of every tag whose slug contains the company name after discarding obvious substring false positives. Structured-record figures read the count field of the exact <name>-organization term where one exists. The created_at and record-quality figures sample 669 timestamped terms drawn from pages 1, 50, 120, 200, 300, 400, 451 and 452 of 452, not the full 45,138, so they establish the shape and direction of the population rather than exact annual totals. Spread sampling is required here: orderby is silently ignored on this install, so sequential pagination returns term_id order — oldest first — and sampling only the leading pages produces a false abandonment signal. Counts are as reported by each API and reflect the publications' own records, not an independent audit of article text.

Correction note. The first version of this article, published 10 September 2026, measured only category and post_tag, skipped /wp-json/wp/v2/taxonomies, and therefore missed the custom namespace that held the answer. The first correction then trusted an unproven ordering parameter and overstated abandonment. We are leaving the URL and the corrected analysis in place rather than withdrawing the piece, because the failure mode is the same one the article is about: a confident claim about a system, derived from the namespace that was easy to query rather than the one that held the answer.