Author Pages & Entity Building: Becoming a Name Google Knows

Google doesn’t just index pages — it maintains a map of things: people, businesses, places, and how they connect. That map is the Knowledge Graph, and its units are entities. When the author of your content is a recognised entity with a real footprint, every article carries that reputation. When the byline is a name Google can’t connect to anything, it carries nothing. This lesson makes you connectable.

Entities: How Google Thinks About “Who”

An entity is a distinct thing Google has identified and stored knowledge about — with properties (occupation, location, works) and relationships (founded X, writes for Y). You’ve met entity thinking twice already: Lesson 1.1‘s example of how “Apple” the company gets distinguished from apple the fruit, and Lesson 1.2‘s language systems that understand meaning, not strings.

The same applies to people and brands. When Google encounters your byline, it tries to resolve the question: which person is this, and what do we know about them? Two possible outcomes:

• Resolved entity: the name connects to an author page, social profiles, other publications, mentions — a person with topical history. The authoritativeness and trust components of E-E-A-T (Lesson 5.2) now have something to attach to.
• Unresolved string: the name matches nothing anywhere. It provides identity theatre — a byline exists — but no verifiable substance behind it. After the update cycles that rewarded verifiable authorship, this difference is worth real ranking movement, especially anywhere near YMYL territory.

The Proper Author Page

Every author on your site gets one page — typically /author/name/ — that acts as the entity’s home base. WordPress auto-generates author archives, but the default (a bare list of posts) wastes the opportunity. A proper author page contains:

Then link the whole system together: every article’s byline links to the author page, and the author page becomes part of your internal linking fabric (Lesson 3.4) rather than a dead-end archive.

Person Schema and sameAs: The Machine-Readable Identity

Now make the identity explicit with schema (Lesson 3.6). The key property is sameAs — a list of URLs declaring “this person here is the same person there.” It’s the single strongest identity-resolution signal you control:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Asha Kulkarni",
  "url": "https://example.in/author/asha-kulkarni/",
  "image": "https://example.in/photos/asha.jpg",
  "jobTitle": "Founder & Head Baker",
  "worksFor": { "@type": "Organization", "name": "Sweet Layers Home Bakery" },
  "knowsAbout": ["Custom cakes", "Baking", "Home food business"],
  "sameAs": [
    "https://www.linkedin.com/in/asha-kulkarni",
    "https://www.instagram.com/sweetlayers.pune",
    "https://www.youtube.com/@sweetlayers"
  ]
}
</script>

Placement and plumbing:

• This block belongs on the author page (its canonical home), and Article schema on each post should reference the author by name and URL — connecting every article to the entity. Rank Math handles the article-side automatically when author profiles are filled in; the enriched Person block above can go on the author page via your code-snippet tool.
• Same treatment for the brand: your Organization schema (Lesson 3.6) gets its own sameAs array — the business’s social profiles, directory listings, YouTube channel — building the company entity in parallel with the person.

Consistency Across the Web: The Off-Site Half

Schema declares the connections; the connected profiles must then corroborate each other. The working rule is boring and powerful — same name, same photo, same core bio, everywhere:

1. Audit your existing profiles (LinkedIn, social platforms, YouTube, any site you’ve written for): do they use consistent naming and describe the same person with the same specialisation? Variations (“V. Kulkarni” here, a nickname there, three different job descriptions) fragment the entity.
2. Fill the bios with the same verifiable specifics as your author page — the claims should match across surfaces, because matching claims are what resolution algorithms (and sceptical humans) check.
3. Get the name published elsewhere in the topic: genuinely useful guest contributions, industry publications, podcast appearances, event talks — each adds an independent corroborating node. This overlaps deliberately with Module 6: the same activities that earn authority links also build the author entity. One effort, two assets.

The Knowledge Graph and Brand Searches

Two compounding payoffs arrive as the entity matures:

• Knowledge Graph entry: with enough consistent, corroborated presence, Google may create a Knowledge Graph entity for the person or brand — sometimes surfacing as the knowledge panel from Lesson 1.4. There’s no application form; it emerges from the footprint this lesson builds. (If a panel appears, claim it via the “Claim this knowledge panel” flow to gain suggestion rights.)
• Brand searches as a ranking asset: when people search your name or brand directly — “sweet layers pune”, “asha kulkarni cakes” — it demonstrates the most unfakeable authority signal that exists: real-world demand for you specifically. Navigational demand (Lesson 2.1) is also the one keyword category competitors can never take. Everything that puts your name in front of your market — the YouTube channel, the packaging, the word of mouth — feeds this signal.