Your About Page Is an Entity Document

Your about page is the document a machine reads to work out what your company is, which makes it an entity document rather than a brand story. Written as a brand story it says almost nothing a retrieval system can use. Written as an entity document it states, in plain sentences a stranger could verify, what the company is called, what it sells, who it sells to, when it started and who runs it.

This is the cheapest page on your site to fix and the one most likely to be doing nothing at the moment. It is also the page every engine reaches for when somebody asks what your company is, which is the question everything else depends on.

Why this page and not another

When a system needs to decide which company a name refers to, it looks for a page that makes an unambiguous claim about identity. Your homepage is usually positioning rather than description. Your product pages describe features. The about page is the only one conventionally expected to answer the question directly, so it carries weight beyond its traffic.

The failure is almost never technical. It is that the page has been written to make a reader feel something, so it opens with a sentence about believing the world deserves better tooling and never states what the company sells. That page is unusable for entity resolution and it is extremely common.

The test. Read your about page and ask whether a stranger could answer four questions from it alone. What does this company sell, to whom, since when, and where is it based. If any answer requires inference, a machine will infer too, and it will sometimes infer wrong.

What an entity document actually contains

Six facts, stated once, in prose rather than only in markup. The markup matters and it is the second step. If the visible page contradicts the structured data, the structured data is what gets discounted.

Fact	Why a machine wants it	Common failure
Legal and trading name	Distinguishes you from similarly named companies	Only the brand name appears anywhere
What you sell, plainly	Places you in a category without guessing	A mission statement stands in for a description
Who it is for	Narrows which questions you are a candidate for	Aimed at everyone, so relevant to no query
Founding year	A strong disambiguation signal and easy to verify	Absent, or only in a press kit PDF
Location	Separates you from same-named firms elsewhere	Buried in a footer or omitted entirely
Named people	Connects the company to verifiable individuals	A team page with first names only

Six facts. Most about pages carry two of them, and usually not the two that disambiguate.

The opening paragraph, rewritten

The whole technique is visible in one paragraph, so here is the same company written twice.

We believe legal teams deserve better tools. Founded by people who lived the problem, we are on a mission to make contract work feel less like paperwork and more like progress.
Reads fine. States nothing verifiable

Nothing in that can be checked, and nothing in it tells a machine what the company sells or to whom. It could be a law firm, a consultancy or a stationery brand.

Clausewise is contract review software for in-house legal teams at mid-market companies. The company was founded in 2019 and is based in Manchester. It was started by Jane Okafor and Tom Reilly after five years running legal operations at a logistics group.
Same tone, six facts, all checkable

The second version is not less human. It is more specific, which reads as more confident rather than less warm. Every clause is verifiable, which is precisely the property that makes it safe for a system to repeat.

Then state it in markup

The prose is the primary signal. The markup makes it unambiguous and connects your record to records elsewhere. One block, on the about page, referencing the same identifier your other pages use.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Clausewise",
  "legalName": "Clausewise Software Ltd",
  "url": "https://example.com/",
  "foundingDate": "2019",
  "description": "Contract review software for in-house legal teams at mid-market companies.",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Manchester",
    "addressCountry": "GB"
  },
  "founder": [
    { "@type": "Person", "name": "Jane Okafor" },
    { "@type": "Person", "name": "Tom Reilly" }
  ],
  "sameAs": [
    "https://www.wikidata.org/wiki/Q00000000",
    "https://www.linkedin.com/company/clausewise",
    "https://www.crunchbase.com/organization/clausewise"
  ]
}

The Organization type carries considerably more properties than this and you should resist most of them. Six accurate facts beat twenty fields where four are stale, because the stale ones are the ones that get quoted back at you eighteen months later.

The sameAs array is the part worth arguing about.

It is the only line in that block that connects your name to a record somewhere else, which is what disambiguation actually requires. It is also the line almost nobody fills in, so it remains available.

If you want to know whether your entity currently resolves at all, that check is included in our free AI visibility check, and the answer is frequently that a differently sized company in another sector owns your name.

Four mistakes that undo the work

The markup and the page disagree. A founding year in the JSON that contradicts the prose gets the whole block discounted rather than just that field.
Every page declares its own organisation block. They drift, they conflict, and a system reading two contradictory claims about you trusts neither. Declare once, reference everywhere.
The identifier moves. A migration changes the @id and every reference pointing at it silently breaks. Nothing looks wrong on the page.
It is written and never revisited. Companies change what they sell and to whom, and the about page is the last thing anybody updates. Stale identity is worse than thin identity, because it is confidently wrong.

Fifteen minutes, in order

Read your about page and mark which of the six facts are stated in plain prose. Most companies find two or three.
Rewrite the opening paragraph so a stranger could answer all four identity questions from it alone.
Add one Organization block with a stable identifier and a populated sameAs array.
Check every other page for a competing organisation block and remove the duplicates.
Put a calendar reminder to reread it after any repositioning, because that is when it silently goes wrong.

That is the entire job. It does not need a project, it will not show up in a traffic report, and it is a prerequisite for a system being willing to name you at all.

The team page does more work than people expect

Identity is not carried by the about page alone. A company connected to verifiable individuals is easier to resolve than one that appears to have no people, and the team page is where that connection either exists or does not.

The version that helps has full names, real roles and a link to a profile that exists elsewhere. The version that does nothing has first names, playful job titles and photographs. The second is friendlier and gives a machine nothing to attach.

This matters more than it sounds because people are among the best-documented entities on the internet. A founder with a professional profile, conference talks or published writing is already a resolved entity, and connecting your company to them lends the company some of that resolution.

If you do not have an about page

Some companies genuinely do not, usually because the site was built as a product marketing exercise and nobody wanted a page that felt corporate. The fix is not to build a long one.

A single page at a stable URL carrying the six facts, four paragraphs, no photography and no manifesto is sufficient. It will get almost no human traffic and that is fine, because its job is to be the canonical answer to a question a machine asks. Judging it by pageviews is judging a passport by how nice it looks.

How to check whether any of this worked

Wait a few weeks, then open a fresh session with no account history and ask an assistant what your company is. Compare the answer against the six facts you published.

What usually improves first is specificity. The answer stops hedging and starts naming your category and your buyer correctly. Founding year and location tend to follow later, and third-party facts you cannot control may lag by months or never arrive. Partial improvement is the normal outcome and it is enough, because the goal was making you safe to describe rather than making the description complete.

A final word on tone, since this is the part people resist. Writing an entity document does not require abandoning your voice, and the instinct that it does is why so many about pages say nothing. Specificity reads as confidence. A company that states plainly what it sells, to whom, and since when sounds more assured than one gesturing at a mission, and it happens to be the version a machine can also use. Those two audiences want the same thing more often than marketing convention assumes.

Treat the whole exercise as maintenance rather than a project. The page goes stale the moment the company changes what it sells or who it sells to, and that happens more often than anybody schedules for. A reminder attached to your repositioning process is worth more than a perfect first draft, because the first draft is the easy part and the drift is what actually costs you.

This sits at step four of the technical playbook, after crawler access and rendering. Doing it before those two is doing careful work on a page nobody can fetch.

Your About Page Is an Entity Document. Write It Like One.