You probably heard that adding author schema boosts rankings. It does not. Google explicitly states that E-E-A-T itself isn’t a specific ranking factor, and there is no dedicated author rich result in its Search Gallery.
However, assuming structured data is useless because it doesn’t move the needle on positions is a dangerous misconception. In the AI search era, author schema is the critical mechanism for disambiguating entities. It proves topical authority to both human readers and language models that rely on clear, machine-readable identity signals.
This is a practical guide to the specific Person fields that carry those signals. We will look at how to correctly mark up your author credentials so search engines can distinguish your unique expertise from generic content.
Which Person fields actually carry author credentials?
The author property in your JSON-LD is just a pointer. The real value lies in the Person object it references. For E-E-A-T signals, search engines need to resolve who is behind the content, and they do this by reading the specific fields within that entity.
A Person entity connects your byline to a persistent digital identity. This connection helps systems distinguish your author from others with similar names. The following fields are critical for building that distinct, verifiable identity.
The power of the bio page link
Among all optional fields, author.url is the most impactful. This property should link directly to a unique, verifiable bio page or author archive. Without it, the author remains an anonymous string of text in the code. With it, you provide a destination where readers—and machines—can confirm the author’s existence and background.
This link creates a direct path from the article to the person. It allows search engines to associate the content with a specific, stable web presence. If you don’t have a dedicated page, consider creating one; it is the anchor point for your author credentials.
Providing professional context
jobTitle and worksFor offer the professional context that helps search engines categorize an author’s expertise. These fields don’t just list a name; they define the role and the organization behind it. For example, stating a job title like “Clinical Director” and linking to a worksFor entity like a specific hospital provides immediate authority for medical topics.
Together, these fields transform a generic name into a professional entity. They give search engines the data needed to understand the domain in which the author operates. By combining these with the author.url link, you create a complete, machine-readable profile that supports topical relevance and trust.
Using knowsAbout and sameAs to signal topical authority
The knowsAbout property serves as the explicit bridge between an author and their specific field of expertise. In structured data, it allows you to define a list of topics or subjects that the author is considered an expert in. This is not a vague field for general interests; it is a precise declaration of competency. For a medical content team, this might include specific clinical areas like “Cardiology” or “Pharmacology.” For a tech blog, it might be “Machine Learning” or “Cybersecurity.” Google recommends keeping this array concise, typically between three and five entries. If you list ten topics, you risk diluting the signal. The goal is to help search engines categorize the author accurately within a specific niche, which supports the assessment of expertise.
The Hierarchy of Trust in sameAs Links
While knowsAbout defines what the author knows, sameAs defines who they are. This property links to other web pages that represent the same real-world entity, effectively connecting your author schema to a broader digital footprint. The order and quality of these links matter. High-trust, verified profiles should always take precedence over social media handles. A link to a Wikipedia page, if it exists, is the strongest possible signal. Similarly, a Wikidata entry is valuable because it aggregates data from multiple sources and provides a unique, persistent identifier for the entity. If a Wikipedia entry is not available, a verified LinkedIn profile or a professional bio page on a reputable industry site is the next best option. These sources provide the verification layer that social media profiles often lack.
Avoiding Broken Links in Entity Data
A common mistake in author schema implementation is padding the sameAs array with broken or dead links. This is counterproductive. If a linked profile has been deleted or returns an error, it undermines the credibility of the entire entity graph. Search engines use these links to disambiguate entities. A broken link suggests that the data is either outdated or unreliable, which can actively hurt the author’s profile in the eyes of the search engine. Always audit your sameAs links before publishing. If a link is broken, remove it. It is better to have two or three valid, high-quality links than ten broken or low-quality ones. This ensures that the entity remains clear and consistent across the web, supporting long-term visibility rather than short-term volume.
Extending your author entity with ProfilePage structured data
The most common gap in author schema implementation is treating the blog post as the only surface where identity matters. In reality, your author archive page—such as /author/jane-doe/—is a high-value signal that should carry its own ProfilePage structured data. Google explicitly documents “an author page on a news site” and “an About Me page on a blog site” as valid use cases for this schema type. By marking up these pages correctly, you give search engines a dedicated, verifiable location to anchor the author’s identity, which reinforces the signals you’ve already embedded in individual posts.
To make this work, you must use the same Person @id across all posts and the profile page. This identifier acts as a thread connecting every instance of the author within your entity graph. If a post references @id: https://yoursite.com/people/jane-doe, the mainEntity of the ProfilePage on the author archive must reference that exact same string. This consistency ensures that the structured data for the bio and the structured data for the articles are recognized as the same entity, rather than two disconnected fragments. Without this link, the author.url property on your posts has no destination to resolve to, and the entity graph remains fragmented.
Finally, when structuring the ProfilePage, do not invent new properties to hold the author’s bio. The description property is the correct place to put the byline or credential text. This is a subtle but critical distinction: the description on a ProfilePage is what search engines and AI models pull to answer queries like “Who is Jane Doe?” or to summarize an author’s background. Keeping the Person object’s @id consistent and using description for the narrative bio ensures that your author schema not only validates in developer tools but also provides a coherent, machine-readable story about your team’s expertise.
Why author schema is a clarity layer, not a ranking switch
Structured data does not replace the work of writing a strong, visible byline and a substantive bio page. If your reader cannot see who wrote the piece, the markup in the HTML source adds nothing to the human experience. Author schema is a supporting layer, not a primary one; it only functions when the underlying content is transparent and credible.
The real value of this structured data lies in removing ambiguity for automated systems. Both Google’s crawlers and modern AI models rely on clear entity signals to attribute expertise to a specific individual. When you provide a consistent Person entity, you help these systems distinguish your author from others with similar names or topics, which supports how E-E-A-T signals are evaluated in the background. Think of it as a way to define the “who” so that the “what” and “how” of your content land with the right authority context.
Rather than treating structured data as a technical shortcut to boost rankings, focus on the identity of the person behind the content. The goal is to make the author a recognizable, verifiable entity in the wider web graph. If the identity is clear and consistent, the machine-readable data naturally reinforces that clarity for any system parsing your site.
Frequently asked questions about author credentials in structured data
We often see confusion about how these signals actually function under the hood. Here is how to separate the technical reality from common myths.
Person schema versus Author schema
There is no distinct “Author” type in schema.org. The term “author schema” is a community shorthand for the author property within an Article or BlogPosting object. That property holds a value, which is usually a Person object (or an Organization for brand pages). So when you audit your markup, you are looking for a Person entity linked to the article, not a standalone “Author” entity.
Does it move the needle on rankings?
No. Google has stated that E-E-A-T is not a direct ranking factor in the traditional sense. However, author credentials provided via structured data are the machine-readable way to disambiguate who is behind the content. This clarity supports the broader evaluation of your page’s expertise and trustworthiness, especially as AI systems increasingly rely on explicit entity signals to cite sources.
How to verify your current setup
The fastest way to check if your site already has the right data is to use the Rich Results Test. Enter a URL and look at the “Page Information” or structured data output. If you do not see a Person object linked to the author property, you may need to adjust your SEO plugin settings or add custom JSON-LD. For a deeper check, view the page source and search for the @type: "Person" string to ensure the entity is present and correctly linked.
The least technical change you can make is filling out your WordPress user profiles. This ensures your SEO plugin has actual data to output in the JSON-LD, rather than leaving fields blank or generic. Once that is in place, a quick validation test on a single post confirms your author schema is rendering correctly before you worry about scaling the markup site-wide.
