---
title: "TechCrunch's Entity Registry Still Grows, But Hollowed Out"
description: "TechCrunch runs a 45,138-term Crunchbase-linked entity taxonomy, but recent records are hollow: 2020-2024 sampled records carry Crunchbase URLs only 12% of the time and attach to coverage 3% of the time."
canonical: https://authoritytech.io/blog/techcrunch-company-categorization-framework
last-updated: 2026-09-10
---

# TechCrunch's Entity Registry Still Grows, But Hollowed Out

TechCrunch runs a 45,138-term Crunchbase-linked entity taxonomy, but recent records are hollow: 2020-2024 sampled records carry Crunchbase URLs only 12% of the time and attach to coverage 3% of the time.

Canonical URL: https://authoritytech.io/blog/techcrunch-company-categorization-framework
Published: 2026-09-10
Author: authoritytech
Topic: Machine Relations

> **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:

```json
{
  "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](https://en.wikipedia.org/wiki/TechCrunch), 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](https://techcrunch.com/category/startups/) 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](https://www.msci.com/our-solutions/indexes/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](https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei) 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](https://www.crunchbase.com/) 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](https://pmc.ncbi.nlm.nih.gov/articles/PMC8886868/) 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](https://w3techs.com/technologies/details/cm-wordpress), 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](https://schema.org/Organization) record, marked up the way [Google's structured data documentation](https://developers.google.com/search/docs/appearance/structured-data/organization) 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](https://www.wikidata.org/wiki/Q1022366) — TechCrunch's own is Q1022366 — is the join key that a large share of entity-resolution pipelines use, directly or through derivatives like [DBpedia](https://www.dbpedia.org/). Research institutions have [ROR](https://ror.org/about/), legal entities have LEI, and the [W3C Organization Ontology](https://www.w3.org/TR/vocab-org/) 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.

## Links

- [Blog Index](https://authoritytech.io/blog.md)
- [Home](https://authoritytech.io/index.md)