How to Use Schema Markup on an Author Website

To use schema markup on an author website, describe yourself once with Person markup on your about page (wrapped in ProfilePage), mark up each essay or post as an Article whose author points back to that page, and add Book or Review markup only where the page really is about a book or a review. Write it in JSON-LD, check it with Google's Rich Results Test and the Schema Markup Validator, and keep every value identical to what readers can see. Structured data helps search engines understand who wrote what; it does not guarantee any special display, and Google states that no special schema is needed to appear in its AI features (checked October 2026).

What structured data can and cannot do for a writer

Schema markup is a shared vocabulary for describing things on a web page in a form machines can read. The vocabulary lives at schema.org, a collaborative project whose founding companies were Google, Microsoft, Yahoo and Yandex and which has run through a W3C community group since April 2015. You place a small block of code on a page that says, in effect, "this page is about a person called X, and this article was written by X".

Google's introduction to structured data says it uses this markup to understand page content and to gather information about the people, books and companies it mentions. That is the real value for authors: disambiguation. If you share a name with a footballer or a politician, consistent markup and links to your verified profiles give search engines firmer evidence about which pages belong to you.

What markup cannot do is force a result. Google's general structured data guidelines are blunt: correct markup "enables a feature to be present, it does not guarantee that it will be present". The set of features has also been shrinking. Google cut FAQ rich results to government and health sites in 2023 and then, according to its documentation changelog, stopped showing them altogether from 7 May 2026. So treat the markup as a precise description of your work, not a ranking trick.

Which schema types suit an author site

Google's list of supported structured data features (last updated 16 October 2026 when we checked) contains several that map cleanly onto a writer's site, and a few that do not.

Two older ideas from many author-site guides are now out of date. HowTo rich results were retired in September 2023, and FAQ rich results are gone too, so neither is worth building a site around. If you want to understand where FAQ markup stands today, our separate guide covers it in detail on uniblog.org.

Person and ProfilePage on your about page

The ProfilePage documentation lists an "About Me" page on a blog and an author page on a news site as valid uses. The page's primary focus must be a single person or organisation affiliated with the site, so your homepage, if it mixes news, books and a shop, is usually the wrong place. The only required property is mainEntity, and the Person inside it needs a name.

{
 "@context": "https://schema.org",
 "@type": "ProfilePage",
 "dateModified": "2026-10-01T09:00:00+01:00",
 "mainEntity": {
 "@type": "Person",
 "@id": "https://www.example.com/about#person",
 "name": "Jane Example",
 "description": "Literary critic and essayist",
 "image": "https://www.example.com/images/jane-example.jpg",
 "sameAs": [
 "https://orcid.org/0000-0000-0000-0000",
 "https://www.example-publisher.com/authors/jane-example"
 ]
 }
}

A few details from Google's guidance are easy to miss. Put your real name in name and any handle in alternateName. Use description for "the user's byline or applicable credential". If you have no photo, leave image out rather than adding a placeholder; when you do include one, Google recommends high-resolution images of at least 50,000 pixels (width multiplied by height).

The sameAs property is defined by schema.org as the URL of a reference page that unambiguously indicates the item's identity, with Wikipedia, Wikidata or an official website given as examples. For writers, good candidates are your publisher's author page, a literary agency listing, an ORCID iD if you publish academically, and social profiles you actually maintain. The full list of Person properties is long; resist the urge to fill it. Every value has to match something visible on the page.

Article markup for essays and columns

Google's Article documentation covers Article, NewsArticle and BlogPosting, and it notes that there are no required properties. The recommended ones are author, headline, image, datePublished and dateModified, with dates in ISO 8601 format and, ideally, a time zone.

{
 "@context": "https://schema.org",
 "@type": "BlogPosting",
 "headline": "Rereading Middlemarch at Forty",
 "datePublished": "2026-09-14T08:00:00+01:00",
 "dateModified": "2026-09-20T10:30:00+01:00",
 "image": ["https://www.example.com/images/middlemarch-essay.jpg"],
 "author": {
 "@type": "Person",
 "@id": "https://www.example.com/about#person",
 "name": "Jane Example",
 "url": "https://www.example.com/about"
 }
}

Google's author markup best practices are worth following to the letter. Include every author shown on the page, each in their own author entry rather than "Jane Example, John Example" in one field. Put only the name in author.name: no job title, no publisher, no honorifics. Google "strongly" recommends adding @type and url (or sameAs), and says that if the URL points to an internal profile page, that page should carry ProfilePage markup. Linking each post's author to your about page with the same @id is what ties the whole site together.

Books and reviews for novelists and critics

The Book type on schema.org covers properties such as isbn, bookFormat and numberOfPages, and marking up a book page helps describe it accurately. Be clear about what it will not do. Google's Book actions feature, which adds buy and borrow links to knowledge panels, is "limited to book providers with a wide selection of available books" and runs through a data feed after an interest form and onboarding. An individual author's site will not qualify on its own.

Critics have a more direct route. Google's review snippet guidelines accept Review markup about a Book, Movie, Event, Recipe, MusicRecording, CreativeWorkSeries and other creative types. The required pieces are the review's author (a real name, under 100 characters), the itemReviewed with its name, and normally a reviewRating. Ratings default to a five-point scale, so a review scored out of ten needs bestRating set to 10.

{
 "@context": "https://schema.org",
 "@type": "Review",
 "itemReviewed": {
 "@type": "Book",
 "name": "The Example Novel",
 "author": { "@type": "Person", "name": "A. N. Author" }
 },
 "reviewRating": { "@type": "Rating", "ratingValue": 8, "bestRating": 10 },
 "author": { "@type": "Person", "name": "Jane Example" }
}

Google adds conditions critics should respect. The review text and rating must be visible on the page. A review must be about a specific item, not a round-up of ten titles. If you received a free copy, disclose it, because Google's guidelines exclude "reviews written in exchange for a benefit" that do not clearly disclose the incentive. If you do not score books, you can drop reviewRating entirely: Google says the rating can be omitted when the markup contains both an author and a review date.

Where the code goes and how to test it

Google supports JSON-LD, Microdata and RDFa, and recommends JSON-LD as the easiest to maintain. Contrary to a common myth, the JSON-LD block does not have to sit in the head: the introduction says it can be embedded in a script tag in the head or the body. Most website builders and content management systems either generate basic markup or let you paste a code block into a page or template, so you rarely need to edit theme files by hand.

Test twice. Google's Rich Results Test shows which Google features a page or snippet is eligible for and flags errors. Its help page notes that the default test agent is a smartphone and that the tool ignores comments inside JSON-LD even though the JSON-LD standard does not allow them, so remove comments before publishing. Then run the same code through the Schema Markup Validator, which checks schema.org syntax generally, including types Google no longer uses.

Once the site is live, Search Console shows how Google reads it over time. Its rich result reports currently include Profile pages, Review snippets and Breadcrumbs, among others (checked October 2026).

Mistakes that cost eligibility

Most problems come from markup that drifts away from the page. Google's general guidelines list the ones that matter for writers:

• Marking up content readers cannot see, such as a rating that only exists in the code.
• Fake or misleading information, including inflated credentials or impersonating another person.
• Putting markup on the wrong page. Structured data belongs on the page it describes.
• Leaving out required properties, which makes the item ineligible.
• Blocking the page with robots.txt, a noindex tag or a login.

The consequence is narrower than many guides suggest. A structured data manual action means a page "loses eligibility for appearance as a rich result; it doesn't affect how the page ranks in Google web search". Annoying, but not the catastrophe it is sometimes made out to be.

The AI question deserves a straight answer too. Google's guide to optimising for generative AI search lists "overfocusing on structured data" as a mistake and says structured data "isn't required for generative AI search, and there's no special schema.org markup you need to add". Its AI features page asks only that structured data match the visible text. Clear, attributed writing on crawlable pages matters more than any markup.

A maintenance routine that takes ten minutes

Structured data goes stale quietly. A routine that fits an author's calendar:

1. When you publish, check the new post's headline and dates match the page, and that the author @id points at your about page.
2. When a book comes out, add its page and Book markup, and add the publisher's author page to your sameAs list.
3. Every few months, open the Search Console rich result reports and fix anything marked invalid.
4. After a redesign or domain move, rerun the Rich Results Test on your about page, one article and one review.
5. Keep an eye on Google's documentation changelog, since supported features continue to change.

Done this way, schema markup becomes a small, accurate description of your work that search engines can trust, which is all it was ever meant to be.