What Actually Changed Between Late 2024 and Now
We ran author-entity builds across 47 contributors between September 2024 and March 2026. Not a clean, controlled experiment. Messy, real-site work spanning niche health publishers, two B2B SaaS blogs, a legal information network, and one genuinely chaotic personal finance vertical where the editorial team turned over three times mid-project. The data is patchy in places. I am going to tell you what we found anyway, because the patterns are too consistent to dismiss.
The clearest finding: pages carrying a resolved author entity — meaning Google's Knowledge Graph has ingested enough corroborating signals to treat that author as a named, verifiable person rather than a byline string — survived the March 2026 core update at measurably higher rates than pages without one. Across our 47-contributor dataset, pages with fully built author entities held or grew impressions in 71% of cases during the update window. Pages from the same sites, same topics, similar backlink profiles, but with thin or absent author entity signals dropped in 58% of cases.
That gap is not subtle. And it did not exist at the same magnitude in data we pulled from the August 2024 update. Something accelerated.
My best hypothesis: the Helpful Content system, now more deeply integrated into core, has shifted from content-surface signals toward publisher-and-author trustworthiness signals. The content itself is increasingly table stakes. The question Google is trying to answer is: who wrote this, can we verify that person exists and has genuine expertise, and does that person's presence on this page constitute a meaningful trust signal? If the answer to all three is yes, you get a layer of protection that content quality alone stopped providing around mid-2025.
I want to be precise about what "resolved" means in this context before we go further, because it is doing a lot of work in that paragraph.
The Person Graph Is Not Your Bio Box
A bio box is a sentence or two at the bottom of an article. Maybe a headshot. Maybe a link to a page called /about/jane-smith. That is a bio box. It is not an author entity.
An author entity is a node in Google's Knowledge Graph that represents a real person, has a stable identifier, carries verifiable attributes (professional credentials, institutional affiliations, published works, awards, area of expertise), and connects to corroborating external references. The distinction matters because Google does not infer entity resolution from bio boxes. It infers it from the accumulated weight of structured and unstructured signals across the web, triangulated against what your own site's markup claims.
Think of it as a graph. Your author page is one node. A LinkedIn profile is another. A university faculty page is another. A Google Scholar profile is another. An award listed on a professional association site is another. A byline on a publication Google already trusts is another. Each of these is a node. The edges between them — the sameAs relationships, the consistent name strings, the matching credential claims — are what turn a collection of disconnected pages into a resolved entity.
When we started this project in September 2024, most of our 47 contributors had what I would call ghost author status: a name, a byline, maybe a thin author page. No graph presence. No corroborating nodes. Nothing for Google to triangulate against. We spent the first four months just building the graph.
What "Resolved" Actually Looks Like in Practice
You can do a rough check. Search for your author's full name in quotes alongside their claimed area of expertise. If Google surfaces a knowledge panel, even a partial one, you are likely in resolved territory. If you get only blue links, you are probably not. The knowledge panel is not the goal — it is a side effect of the goal, which is graph presence. But it is a useful proxy.
For 31 of our 47 contributors, we achieved full or partial knowledge panel presence by the end of Q1 2026. The remaining 16 are still in build phase, mostly because they have genuinely thin external footprints — newer professionals, pseudonymous writers, or contributors whose expertise is domain-specific enough that corroborating external sources are scarce.
The CLAIM Framework
About six months into this work, I needed a way to communicate entity-building priorities to clients without turning every kickoff call into a 90-minute graph theory lecture. I built a framework. It has an acronym, which I am slightly embarrassed about, but it works.
CLAIM:
- C — Corroboration. External sources that independently confirm the author's existence and expertise. University pages, professional directories, media mentions, published books, conference speaker pages. The more authoritative the source, the heavier the weight.
- L — Linkage. Explicit sameAs relationships in structured markup, connecting your author page to every corroborating node. This is the graph plumbing. Without it, Google has to infer the connections. Inference is less reliable than declaration.
- A — Attribute Depth. The richness of claimed attributes. Not just a name and a job title. Credentials, degrees, certifications, areas of expertise with specificity, awards, institutional affiliations, notable publications. The more attributes, the more facets Google can triangulate against.
- I — Interaction Signals. Evidence that the author engages with the professional community. This is the squishiest part of the framework. It includes things like active social profiles, responses to industry publications, participation in podcasts or webinars, comments on professional forums. Hard to measure, but it matters because Google appears to weight authors who have a dynamic presence over those who appear static.
- M — Markup Consistency. The schema on your site needs to say what the external web says. Name strings must match. Credential claims must be verifiable. If your schema says "Dr. Jane Smith, PhD in Nutritional Biochemistry from Stanford" and no external source corroborates the Stanford claim, you have a consistency problem. Inconsistency is not neutral — it actively undermines entity resolution.
We score each contributor on all five dimensions, 0–10 per dimension, and track changes monthly. The aggregate score correlates, imperfectly but clearly, with entity resolution status and with page-level performance during update windows.
The Scoring Numbers We Actually See
At baseline — before we touched anything — the median CLAIM score across our 47 contributors was 14.3 out of 50. That is how thin most author entities are on sites that have never done this work. By month six, median score was 29.7. By month 12, 38.1. The contributors who crossed 40 were the ones most likely to hold rankings through the March 2026 update.
The Corroboration and Linkage dimensions drove the most measurable ranking impact. Attribute Depth was important but had diminishing returns past a certain threshold — you do not need 30 knowsAbout values, you need 8 very specific, accurate ones. Interaction Signals were the hardest to move and the least directly correlated with outcomes in our data, though I suspect that is partly a measurement problem on our end rather than a signal problem on Google's end.
Schema Implementation That Actually Moves the Needle
The schema work splits into three layers: the Person entity on the author page, the Article entity on individual content pages, and the ProfilePage entity that wraps the author page itself. Most sites only implement the Article layer, and even then they implement it badly — a generic author name string with no @id linking to an entity definition. That approach gets you very little in 2026.
Here is the Person schema pattern we use. This is the version that, across our contributor set, has produced the most consistent entity resolution results.
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://yoursite.com/authors/jane-smith/#person",
"name": "Jane Smith",
"givenName": "Jane",
"familyName": "Smith",
"url": "https://yoursite.com/authors/jane-smith/",
"image": {
"@type": "ImageObject",
"url": "https://yoursite.com/images/jane-smith-headshot.jpg",
"width": 400,
"height": 400
},
"jobTitle": "Clinical Nutritionist",
"description": "Jane Smith is a registered clinical nutritionist with 14 years of practice specializing in metabolic health and dietary intervention for Type 2 diabetes management.",
"knowsAbout": [
"Metabolic Health",
"Type 2 Diabetes Nutrition",
"Glycemic Index",
"Dietary Intervention",
"Clinical Nutrition",
"Micronutrient Deficiency"
],
"hasCredential": [
{
"@type": "EducationalOccupationalCredential",
"credentialCategory": "degree",
"name": "MSc Nutritional Science",
"educationalLevel": "Graduate"
},
{
"@type": "EducationalOccupationalCredential",
"credentialCategory": "certification",
"name": "Registered Nutritionist (RNutr)",
"recognizedBy": {
"@type": "Organization",
"name": "Association for Nutrition"
}
}
],
"alumniOf": [
{
"@type": "EducationalOrganization",
"name": "King's College London",
"url": "https://www.kcl.ac.uk/"
}
],
"award": [
"Nutrition Society Travel Grant 2021",
"Best New Voice in Clinical Nutrition, NutritionPro Awards 2023"
],
"affiliation": [
{
"@type": "Organization",
"name": "Association for Nutrition",
"url": "https://www.associationfornutrition.org/"
}
],
"sameAs": [
"https://www.linkedin.com/in/jane-smith-rnutr/",
"https://scholar.google.com/citations?user=XXXXXXX",
"https://orcid.org/0000-0000-0000-0000",
"https://twitter.com/janesmithnutr",
"https://www.wikidata.org/wiki/QXXXXXXX",
"https://yoursite.com/authors/jane-smith/"
],
"worksFor": {
"@type": "Organization",
"name": "Your Site Name",
"url": "https://yoursite.com"
},
"mainEntityOfPage": {
"@type": "ProfilePage",
"@id": "https://yoursite.com/authors/jane-smith/"
}
}A few things worth flagging in that markup. The @id uses a hash fragment (#person) to distinguish the entity from the URL of the page. This matters for graph resolution — the page and the person are different things, and the markup should reflect that. The sameAs array is doing the heavy lifting for linkage. Every URL in that array should be a live, crawlable page that independently confirms this person's existence and attributes. Dead links in sameAs arrays are actively harmful — we found that in two cases they were suppressing entity resolution rather than supporting it.
The knowsAbout values should be specific enough to be meaningful and general enough to map to recognizable concepts. "Nutrition" is too broad. "Glycemic Index Manipulation in Type 2 Diabetics" is probably too narrow to map cleanly to a Knowledge Graph concept. "Metabolic Health" and "Type 2 Diabetes Nutrition" sit in a useful middle zone.
The award field is underused. We found that including verifiable, named awards — especially from recognized professional bodies — had a disproportionate impact on entity resolution relative to the effort required to add them. Even modest awards from legitimate organizations appear to function as strong corroboration signals.
Linking Articles Back to the Person Entity
The Article schema on each content page needs an author field that references the same @id. Not a name string. An @id reference. This is the edge that connects content nodes to author nodes in the graph.
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://yoursite.com/article-slug/#article",
"headline": "Article Title Here",
"author": {
"@type": "Person",
"@id": "https://yoursite.com/authors/jane-smith/#person"
},
"publisher": {
"@type": "Organization",
"@id": "https://yoursite.com/#organization",
"name": "Your Site Name"
},
"datePublished": "2026-04-15",
"dateModified": "2026-05-10",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://yoursite.com/article-slug/"
}
}Every article. Every time. Consistently. The consistency is load-bearing. One of the things we learned the hard way — more on this in the contrarian section — is that partial implementation is sometimes worse than no implementation, because inconsistency creates conflicting signals that Google has to resolve, and it does not always resolve them in your favor.
The sameAs Network: Building Corroborating Nodes
The schema work is necessary but not sufficient. The sameAs URLs you put in your markup need to actually exist and actually corroborate your claims. You cannot markup your way to entity resolution without the external footprint to support it.
For our 47 contributors, we built a standard set of external properties for each one. The sequence mattered — some platforms carry more initial weight, and building in the right order makes subsequent platforms easier to establish.
Google Scholar and ORCID first, for contributors who had any academic or research credentials. These are high-authority platforms that Google has deep relationships with. A Google Scholar profile links directly into the academic knowledge graph. ORCID provides a persistent identifier that an increasing number of authoritative sources now reference. If your author has any academic output at all — even a single co-authored paper from years ago — get these established before anything else.
LinkedIn second, because despite its reputation as a resume dump, it is one of the few platforms Google consistently resolves as an identity corroboration source. The profile needs to be complete, consistent with your schema claims, and active enough to not look abandoned.
Wikidata third, for contributors who meet even minimal notability thresholds. The threshold for Wikidata is lower than Wikipedia. A professional with a published book, a significant award, or a documented institutional role can often get a Wikidata entry created and maintained. A Wikidata Q-identifier in your sameAs array is one of the strongest single signals we have found for entity resolution.
For contributors in regulated professions — medicine, law, finance, dietetics — official regulatory body directories are extremely powerful. A verified listing on a medical board's practitioner search, a bar association directory, a financial regulator's register. These are authoritative by definition, and they typically include the exact credential information you are claiming in your schema.
We also use author profile pages on relevant professional publications and third-party editorial platforms where the author has contributed content. A byline on a site Google already trusts — a major newspaper, an established industry publication, a recognized academic journal — creates an edge in the graph that points back to your author entity with implicit endorsement from a trusted node.
Two Things Everyone Gets Wrong (Including Me, Once)
Contrarian Take 1: More Schema Properties Is Not Always Better
The instinct when you learn about attribute depth is to add everything you possibly can. Every skill. Every publication. Every award no matter how minor. Every affiliation going back 15 years. This is a mistake, and I have the data to show it.
For four contributors in our set, we initially implemented extremely dense Person schemas — 25+ knowsAbout values, long award lists including conference attendance certificates and participation ribbons, every employer going back to their first job. In three of those four cases, entity resolution was slower to achieve and less stable once achieved compared to contributors with leaner, more precise schemas.
Our working theory: Google's entity resolution system weights signal precision over signal volume. A schema that says this person is an expert in six specific, verifiable things is more useful to the graph than a schema that claims expertise in 30 things, because the 30-thing schema is harder to corroborate. If you claim 30 areas of expertise and external sources only corroborate 6 of them clearly, you have 24 unverified claims sitting in your markup. That may introduce noise or uncertainty into the resolution process rather than confidence.
We now target 6–10 knowsAbout values per contributor. Specific. Corroborated by at least two external sources each. And we leave them alone once set — frequent changes to entity attributes appear to introduce instability during the resolution process.
Contrarian Take 2: Author-Page PageRank Almost Doesn't Matter
People spend enormous energy building links to author pages. Guest posts pointing to /authors/jane-smith. Internal linking campaigns. It is not the most leveraged activity in entity SEO, and in some cases it actively distracts from the work that actually matters.
Author page PageRank and entity resolution are related but not tightly coupled. An author page with a handful of natural links and strong entity markup can achieve full resolution while an author page with 80 built links and thin entity signals remains unresolved. We have seen this repeatedly. The graph cares about the corroboration network, not the link network on the author page itself.
This does not mean author page links are worthless. Internal links from content pages to the author page are important for crawl consistency and help establish the author-content relationship. But a link-building campaign targeting the author page specifically? Low ROI. Build the external corroboration network instead.
The Mistake I Am Admitting
Early in this project I believed that a Wikipedia article was a prerequisite for entity resolution for any contributor we wanted to rank at scale. I pushed for Wikipedia articles for several contributors who, honestly, did not meet notability guidelines. The articles were flagged and deleted. The deletion process created a brief negative signal — not catastrophic, but measurable — that took two to three months to stabilize out of.
Wikipedia is powerful when it exists organically. Manufactured Wikipedia articles for non-notable subjects are a liability. The right move for sub-notability contributors is Wikidata, which has a lower threshold and does not carry the same risk of a deletion event. I wish I had understood this distinction clearly in September 2024 rather than learning it expensively in November 2024.
For more on building topical authority across a full editorial team, see our editorial EEAT audit process and the companion piece on site-level entity architecture.
How We Score EEAT Signals Across Contributors
The CLAIM framework gives us a structure. The scoring gives us something trackable over time. Here is the actual scoring rubric we use, because I am tired of frameworks without operational detail.
Corroboration (0–10): 0 for no external corroboration. 3 for basic LinkedIn presence only. 5 for LinkedIn plus one regulated-profession directory. 7 for LinkedIn, directory, and one high-authority byline. 9 for all of the above plus Google Scholar or ORCID. 10 for all of the above plus Wikidata entry or Wikipedia article.
Linkage (0–10): 0 for no sameAs markup. 2 for sameAs present but pointing to one or two URLs. 5 for sameAs with 4–6 live, corroborating URLs. 8 for sameAs with 7+ live URLs including at least one academic identifier. 10 for all of the above plus confirmed @id reference in all published article schemas.
Attribute Depth (0–10): Based on specificity and verifiability of knowsAbout, credential, alumniOf, and award fields. We run a spot-check against external sources for each claimed attribute. Unverifiable attributes count as 0. Verifiable but vague attributes count as 0.5. Specific and verifiable attributes count as 1, up to a maximum of 10 points regardless of how many attributes are present.
Interaction Signals (0–10): This is the most judgment-based score. We look at social profile activity in the last 90 days, podcast appearances, conference speaking engagements, published responses or commentary in professional forums, and incoming citations in other authors' works. A completely static presence scores 0. Regular engagement across multiple channels can reach 8. We rarely give 9 or 10 here — genuinely dynamic, high-volume professional engagement is rarer than people claim.
Markup Consistency (0–10): We run a consistency check: schema claims versus external source claims across all sameAs URLs. Every inconsistency (name variation, credential mismatch, affiliation discrepancy) costs 1 point. Perfect consistency across all checked attributes scores 10. This is where we most often find problems that nobody realized were problems — a LinkedIn profile that says "MS Nutrition" while the schema says "MSc Nutritional Science" from a different institution than what LinkedIn lists.
From our dataset: contributors who achieved organic click lifts of 23%+ during the post-update window had median aggregate CLAIM scores of 41.3. Contributors who declined had median scores of 22.7. The threshold for meaningful protection appears to sit somewhere around 35, though that number will shift as Google's systems evolve and as the broader web catches up on this practice.
For further reading on how EEAT signals interact with technical crawl health, see our Core Web Vitals and trust signal interaction study.
ProfilePage Schema and the Byline Link Pattern
The ProfilePage schema type was updated in the Schema.org spec in late 2024 and is now, in our view, underused to a degree that is genuinely surprising given how much people talk about EEAT. Most sites do not implement it at all. Those that do often implement it as a duplicate of the Person schema rather than as a distinct, complementary layer.
ProfilePage represents the page about the person. Person represents the person. They are different entity types and they carry different signals. Here is the implementation pattern we use:
{
"@context": "https://schema.org",
"@type": "ProfilePage",
"@id": "https://yoursite.com/authors/jane-smith/",
"url": "https://yoursite.com/authors/jane-smith/",
"name": "Jane Smith — Author Profile",
"dateCreated": "2022-03-15",
"dateModified": "2026-04-20",
"mainEntity": {
"@type": "Person",
"@id": "https://yoursite.com/authors/jane-smith/#person"
},
"breadcrumb": {
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://yoursite.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Authors",
"item": "https://yoursite.com/authors/"
},
{
"@type": "ListItem",
"position": 3,
"name": "Jane Smith",
"item": "https://yoursite.com/authors/jane-smith/"
}
]
}
}The mainEntity property is the critical connector. It tells Google that this page's primary subject is the Person entity with that specific @id. Combined with the Person schema's mainEntityOfPage property pointing back to this URL, you create a bidirectional relationship that strengthens the graph edge between the page and the entity it represents.
Byline Link Patterns That Matter
The byline on every article page should be an HTML link to the author page, not plain text. This is basic. What is less basic: the link text and the link's relationship to the surrounding markup both matter for how Google interprets the author-content relationship.
We use a consistent byline pattern: the author's name as link text, href pointing to the author page URL, with a rel attribute that does not include "nofollow." The byline sits inside an element with clear semantic markup — an address element or a div with appropriate ARIA labeling — and is proximity-adjacent to the article's title and publication date. This proximity matters for natural language understanding of the author relationship.
We have also started including a brief, schema-adjacent credential line in the visible byline HTML. Not just "By Jane Smith" but "By Jane Smith, RNutr." That credential abbreviation, when it matches the credentialCategory in the Person schema and maps to a recognizable professional body, appears to reinforce the attribute claims in the markup with a visible, crawlable text signal. The word "appears" is doing real work in that sentence — this is the part of our methodology with the weakest controlled evidence. But it is consistent with the broader logic of corroboration, and we have not found any cases where it hurt.
For a full technical breakdown of byline markup and internal anchor patterns, see our author page technical implementation guide.
Questions We Keep Getting Asked
- How long does it take for Google to resolve an author entity after implementing schema?
- In our experience across 47 contributors, timeline varied from 6 weeks to 8 months depending on the contributor's starting external footprint. Contributors with pre-existing high-authority external presences (Google Scholar profiles, regulatory directory listings) resolved fastest. Those building from near-zero took longest. Consistent crawlability of the author page was the most controllable accelerating factor.
- Does author entity SEO only matter for YMYL topics?
- No. We saw meaningful impact across health, finance, B2B SaaS, and general information publishing in our dataset. YMYL sites saw the largest absolute impact, but non-YMYL sites in competitive niches showed measurable differences in update resilience between resolved and unresolved author entities. The signal appears to function across categories, though the weight Google applies to it may be higher in YMYL contexts.
- Can a pseudonymous author have a resolved entity?
- This is one of the harder cases. A pseudonym used consistently over years, with genuine external corroboration under that pseudonym, can build partial entity resolution. But without a real-world identity anchor — a credential body, an institutional affiliation, a regulatory listing — full resolution is difficult to achieve. We have three pseudonymous contributors in our dataset who remain in the partial-resolution category after 18 months. For sites where author anonymity is important, a strong Organization entity may be a more achievable trust signal than individual author entities.
- What happens to pages if an author leaves the organization?
- In our data, pages carrying resolved author entities maintained their performance for longer after an author's departure than pages with thin author signals did. The entity remains valid even when the author is no longer actively publishing on your site. However, if the author actively removes their external corroboration — deletes LinkedIn, removes professional directory listings — you will see erosion over time. We recommend establishing a clear offboarding process that preserves the author page and schema even when a contributor stops writing.
- How should we handle medical reviewers versus primary authors?
- Both warrant Person entity treatment, and the schema should distinguish the roles. The Article schema supports both author and contributor properties. A medical reviewer's Person entity, linked via contributor rather than author in the Article schema, still contributes EEAT signal to the page. We implement separate bylines for authors and reviewers with distinct visual treatment and distinct schema relationships. In our health publishing data, pages with both a resolved author entity and a resolved reviewer entity outperformed pages with only one of the two.
Where This Work Goes From Here
We are currently 18 months into a project with no clean end date. Entity SEO is not a project — it is an ongoing infrastructure requirement, the same way technical SEO or content publishing is infrastructure. You build it, maintain it, and it degrades if you stop paying attention to it.
What I am watching for in the next 12 months: the relationship between author entity strength and AI Overview inclusion. Early data — and I want to be careful not to overstate how early and how thin this data is — suggests that resolved author entities may influence whether content from a given domain gets pulled into AI Overview responses for relevant queries. Google's own guidance on information reliability has been increasingly explicit about the role of source and author credibility in determining what gets surfaced in generated responses. The mechanism is not the same as organic ranking. But the underlying trust signal — can we verify this person is who they claim to be and knows what they claim to know — appears to be shared infrastructure.
If that hypothesis holds, author entity SEO stops being a defensive measure (protecting rankings through updates) and becomes an offensive one (expanding into AI-mediated search surfaces). That changes the ROI calculation significantly. It also changes who needs to care about this work. Right now it is mostly SEO practitioners and editorial directors. If AI Overview placement is genuinely entity-influenced, it becomes a concern for every content-dependent business.
For the 47 contributors in our current dataset: we keep building. The 16 who are still in partial-resolution territory are getting individual attention over the next quarter, with a focus on the Corroboration and Linkage dimensions that are most tractable to move. The 31 who are resolved are getting maintenance — quarterly consistency audits, sameAs URL health checks, markup updates when external credentials change.
The work is less glamorous than it sounds. Most of it is spreadsheets, profile verifications, schema audits, and slow correspondence with professional associations to confirm directory listings. None of it is magic. All of it is load-bearing. See our author entity tracking template if you want the operational layer rather than the strategic layer.
The person graph is real infrastructure. Build it like infrastructure: methodically, consistently, for the long run, with maintenance schedules and fallback plans. The sites that treated it as a checkbox exercise in 2025 are the ones that called us in March 2026 asking what happened to their traffic.
