Entity Pillar Pages on Your Entity Home Website: Page Architecture for the Age of AI Recommendation
Status: Original concept, first publication Author: Jason Barnard Date: March 2026 Publication: jasonbarnard.com / Strategy Sandbox
SEO built its page architecture around keywords, and for thirty years the logic was sound: topical authority accumulated through well-structured keyword cornerstone pages that captured traffic, earned links, and distributed authority across the site, because the mechanism being served was ranking, and ranking rewarded content signals. That model isn’t wrong. It’s incomplete, and the gap between complete and incomplete is widening with every quarter as recommendation displaces ranking at the decision layer.
Ranking Answers a Query. Recommending Evaluates an Entity.
A keyword cornerstone page tells the algorithm what a piece of content covers. “Technical SEO audit” as a topic signals topical authority for that query. It doesn’t tell the algorithm who the entity publishing that content is, what else that entity is known for, who it works with, where it’s been covered independently, or what track record it has accumulated.
Those identity signals are what recommendation engines evaluate. An LLM deciding whether to name a brand doesn’t run a relevance calculation against the page; it draws on what it has learned about the entity across its training data and from the knowledge graph relationships it has resolved. A brand can rank comfortably for a hundred keyword cornerstone pages and still be invisible in AI recommendations if the entity itself hasn’t been established with enough confidence. Ranking and recommendation are two different problems requiring two different architectural solutions.
Entity Pillar Pages Are Identity Infrastructure, Not Content Anchors
Every entity has facets: the expertise it has demonstrated, the companies it belongs to, the peers it works with, the publications it has appeared in, the events it speaks at, the work it has produced. These facets are the dimensions an AI engine uses to resolve identity, to confirm that the entity it encounters in one context is the same entity it found in another, and to build a model of what that entity does and what it can be trusted for.
An Entity Pillar Page is the authoritative page on your own property for one of those dimensions. The /expertise page that establishes demonstrated knowledge in a specific domain. The /companies page that connects the entity to the organisations it has built or contributed to. The /peers page that places it in a professional network the algorithm already trusts. The /press page that links outward to the independent coverage that corroborates what the entity claims about itself.
These aren’t traffic pages in the traditional sense. They’re identity infrastructure, and their function is to give the algorithm something specific, coherent, and verifiable about one dimension of who this entity is.
The Best Architecture Engineers the Coincidence Between Both Functions
The coincidence between keyword cornerstone pages and Entity Pillar Pages is real, and it’s worth deliberately engineering. The expertise page that ranks for “technical SEO audit” can also serve as the Entity Pillar Page that declares this entity’s demonstrated knowledge in that domain, if it’s built with that second function in mind: explicit entity statements, stable URLs, schema that names relationships, links to corroborating third-party sources that don’t shift with content updates.
For me, this is where the architecture conversation turns practical: a single page that earns its existence by doing both jobs simultaneously compounds value rather than competing with the rest of the site for attention and resource. The brands that hold positions across both eras are the ones that engineer this coincidence rather than stumble into it.
Human Scanners and Machine Resolvers Don’t Always Need the Same Page
Keyword cornerstone pages are structured for human scanners: headings that match search intent, content that addresses the query, calls to action that convert. Entity Pillar Pages need to be structured for machines resolving an identity question: explicit entity statements, schema that declares relationships, links to sources stable enough to function as persistent references across years.
When those two requirements pull in opposite directions, you face an architectural choice. There’s no single correct weighting between keyword architecture and entity pillar architecture across all brands, because the ratio between ranking and recommendation in any given category shifts by industry, geography, audience, and what that audience is using to make its decisions. The practitioner who can read where a brand sits on that spectrum and make the call consciously is doing something that can’t be automated, because it requires judgement about a moving target.
Entity Pillar Pages and Cornerstone Entities Operate at Different Layers
This distinction matters enough to state directly, because both concepts live within entity optimisation and the confusion produces real architectural mistakes.
Cornerstone Entities (see the related article on this site) are the primary entities in your knowledge graph ecosystem: the people, companies, products, and associations closest to your Focus Entity, which AI engines already understand and can use as anchors to resolve and extend their understanding of you. They’re nodes in the knowledge graph, external to your property.
Entity Pillar Pages are the pages on your Entity Home Website that declare and substantiate those entity dimensions. They’re architecture on your own property. A Cornerstone Entity is an external relationship the algorithm has already learned. An Entity Pillar Page is an internal declaration on your website that points toward those relationships.
The two work together: a well-built Entity Pillar Page on your /peers URL should explicitly reference the Cornerstone Entities in your professional network, creating a machine-readable link between your identity declaration and the external nodes the algorithm already has confidence in.
Start with an Audit Against Two Questions
Audit your existing pages against two questions. Does this page rank for queries that matter? Does this page declare a clear, machine-readable entity facet, linked to corroborating evidence? Pages that answer yes to both are already doing both jobs. Pages that answer yes to only one need a decision: can they be extended to serve both, or does the entity pillar function need its own dedicated page?
For most brands that haven’t yet done this work, three or four properly structured Entity Pillar Pages, linked from the Entity Home and connected to the satellite properties they describe, will do more for algorithmic confidence over the next two years than equivalent investment in keyword depth. Not because keyword cornerstone pages have stopped working. Because the identity infrastructure has never been built, and recommendation engines penalise that gap in ways that don’t appear in rank tracking.
The keyword era built traffic, the entity pillar era builds identity, and building pages that serve both eras simultaneously is the architecture problem worth solving now.
Status: Original concept, first publication, March 2026. The Entity Pillar Page framing and the architectural distinction between keyword cornerstone pages and Entity Pillar Pages are original to Jason Barnard and The Kalicube Framework. Free to use with attribution.
The Kalicube Process™™ is an open methodology: free to use, teach, and adapt with attribution. Learn more at kalicube.com/about/the-kalicube-process/
