Schema Markup·3 min read

Structured Data for About Pages: AboutPage Guide

An agency site tells clients what it does on every service page, but only one URL says who the agency actually is. That's why structured data for about pages punches above its weight: it marks the single page where search engines expect to learn about the entity behind the domain. This guide walks through the AboutPage type, shows a worked JSON-LD example for a fictional agency, and covers the mistakes that quietly waste the markup, plus the cases where a different page type is the better call.

Open the tool All insights

What structured data for about pages actually does

One page, one entity.

Picture Northbeam, a twelve person digital agency. Prospects who hear the name search for it, and Google assembles what it knows about the company from dozens of scattered signals. An AboutPage declaration cuts through the noise by flagging the canonical answer: this URL, and no other, is where the organization describes itself. That's valuable for agencies in particular, because their sites are full of pages about other companies, client case studies, and portfolio entries that can muddy entity extraction.

Technically, AboutPage is a subtype of WebPage in the schema.org vocabulary. It inherits every WebPage property, so you're not learning a new structure, just applying a sharper label. There's no rich result attached to it. The payoff shows up in brand queries, knowledge panel accuracy, and the general confidence search engines have about who publishes your content.

A worked AboutPage example for an agency

From form fields to script tag.

Say Northbeam's About page lives at https://northbeam.agency/about-us with the title "About Northbeam | Digital Agency". Feeding those two values plus the publisher details into the generator produces this core output: {"@context":"https://schema.org","@type":"AboutPage","name":"About Northbeam | Digital Agency","url":"https://northbeam.agency/about-us","publisher":{"@type":"Organization","name":"Northbeam","url":"https://northbeam.agency"}}.

The nested publisher is the part worth staring at. Most of the practical value here comes from connecting about page to organization markup through that block: the page entity now points at the company entity by name and URL. When your homepage or footer also declares an Organization with the identical name and URL, the two references corroborate each other, and corroboration is what entity systems are built on.

AboutPage vs WebPage type: which one to declare

Every AboutPage is a WebPage, so why not just use the generic type? Because specificity is free information. Given two labels that are both true, the more precise one tells crawlers strictly more. Reserve plain WebPage for pages that genuinely resist classification, and let your About URL carry the label built for it.

The choice gets murkier on hybrid pages. Plenty of small agency sites merge the story, the team, and a contact form onto one URL. Pick the type matching the page's primary purpose: if the H1 says About Us and the form is a footnote, AboutPage is honest. If contact details dominate, ContactPage fits better. What you shouldn't do is stack both types on one page and let them fight.

AboutPage mistakes that waste the markup

All of these pass a validator. None of them help you.

Validation only proves the JSON parses. These are the errors that survive validation and still cost you:

Publishing the AboutPage block on the wrong URL, or site wide through a shared header template, so ten pages all claim to be the About page.
A publisher name that doesn't match your Organization markup elsewhere, like Northbeam here and Northbeam Digital Ltd in the footer schema.
Bumping dateModified on every deploy while the page text hasn't changed, which trains crawlers to distrust your dates.
Relative image paths like /img/team.jpg instead of absolute URLs, which some parsers resolve incorrectly or discard.
Marking up /about while the page's canonical tag points to /about-us, leaving the schema attached to a URL Google won't index.

Three habits for better AboutPage markup

First, auto-fill from the live page and then correct, rather than typing from memory. The tool pulls your real title tag and meta description, which keeps the schema aligned with what's actually served, and the mismatches you spot while correcting are often worth fixing in the page itself.

Second, keep the schema description consistent with your meta description rather than writing a third version of your pitch. Third, revisit the block when the company changes: a rebrand, a merged entity, or a moved domain makes stale About markup actively misleading, and it's the one page where that stings.

When AboutPage is the wrong tool

If you need subtypes beyond the About context, breadcrumbs in the same block, or an author declaration, the WebPage Schema Generator handles ten page types with publisher, author, and a three level trail in one output. It's the broader instrument; this one is the specialist.

For the company entity itself, with logo, founders, social profiles, and contact points, use the Organization Schema Generator; the AboutPage's small publisher block references that entity but doesn't replace it. And when the page in question is your contact URL rather than your story, the Contact Page Schema tool builds the ContactPage type with a proper ContactPoint instead.