Site Schema: Which Markup Belongs on Each Page?
A site owner can add structured data to a home page, publish an article, and still be unsure what “site schema” should contain. The phrase sounds like one setting for the whole website. In practice, the useful question is more specific: what does this page say about the organization, the article, and the page’s place in the site? Structured data gives machines a standardized description of page information; it does not, by itself, secure a special search appearance. Google’s introduction to structured data makes both the purpose and the limit clear.
My recommendation is to begin with three descriptions when the site actually has the corresponding content: the organization behind the site, each published article, and the breadcrumb trail that helps a visitor move through the site. These are distinct subjects. An organization’s name is not an article’s headline, and an article’s publication date is not a sitewide date. Keeping those distinctions clear makes the markup easier to write and easier to keep accurate when pages change.
The page determines what its schema can honestly say
Schema.org supplies a shared vocabulary of types and properties for describing entities and their relationships. The vocabulary is broad: a site can use its terms to describe an organization, a piece of editorial content, or how a page relates to a wider site. That breadth can tempt a team to treat schema as a catalog of terms to add. I would reverse the process. First identify what a visitor can learn from the page, then choose terms that describe it. A property has little value if its apparent precision exceeds the page’s own information.
Consider an illustrative publication with a home page, an article page, and a navigation path through a guides section. The home page can identify the publication’s organization. The article page can identify the published work, its headline, its author, and its dates. A breadcrumb trail can describe where that article sits in the site’s navigable hierarchy. Those descriptions can coexist because they answer different questions. They become misleading if the article markup is copied unchanged onto every page or if a breadcrumb claims a category path that visitors cannot follow.
This is the first decision to make before choosing a format or filling fields: which statements are true for this particular URL? A site template may supply organization details across pages, while article details vary with each publication. The difference matters when an author changes, an article is updated, or a section is reorganized. The code may be generated by one publishing system, but the values still have to represent the actual page. Google’s guidance says structured data should describe the page on which it appears and should not introduce information absent from that page. Its structured-data introduction is a useful boundary for every later choice.
Give the organization a stable identity
If the site belongs to a named organization, its organization markup should identify that entity rather than serve as a bag of promotional phrases. Google’s Organization guidance covers a named organization and related details, including its website URL and logo. The practical starting point is the organization’s established name and the URL that represents it. Add a logo when the site has an actual logo to represent. Each value should agree with what the site itself presents.
This sounds simple until a site uses several names. A publication may have a brand name, a company name, and a shortened name in its navigation. The markup needs a deliberate answer to “which organization is being described here?” I would use the name and details of the organization the page identifies, rather than merge names because they happen to appear in the same header or footer. If ownership and branding differ, settle the relationship in the visible site information before expecting a structured record to make it clear. Schema can express an identity; it cannot resolve an identity the publisher has left ambiguous.
The logo decision deserves the same restraint. The logo property can carry an organization’s logo, but adding a logo URL is not a promise about what a search result will show. Google’s Organization documentation describes the property while leaving search appearance conditional. This distinction matters in a design review: the team can control whether the markup accurately points to its logo, but it cannot treat a particular display as the acceptance criterion for the markup. If the organization changes its logo or website URL, the structured values need to follow the real change.
I would put organization details under one clear editorial owner, because the same name and logo may be reused across many pages. That is an implementation choice, not a claim that all pages need identical schema. The cost is coordination whenever the brand changes. The benefit is avoiding a situation in which one article names the organization one way and another page names it differently. Where the site has no clearly identified organization, I would postpone rich organization details until the underlying site information is settled.
Let every article describe its own published work
An article page has a different job. Google’s Article guidance describes an editorial work with properties such as headline and author. For a publisher, the question is not “how much Article schema can the template produce?” It is “which headline and author belong to this work?” I would take those values from the published page. A generic site slogan in headline or an organization name used as a substitute for an actual byline would blur the very distinction the markup is meant to express.
The publication and modification dates require particular care. datePublished is about when the article was published; dateModified is about a later change to that article. Google’s Article documentation treats them as separate properties. If an article has not been changed since publication, do not manufacture a later revision date to make it look recent. If it has been revised, the modification date should follow that real publishing history. A date inserted across all articles by a template is a poor substitute for dates belonging to each work.
An illustrative example makes the distinction concrete. Suppose a publication posts a guide on one day and revises that guide on a later day. The guide’s original publication date and its later modification date answer different reader questions. Replacing both with the latest site deployment date would describe the publishing system’s activity, not necessarily the guide’s history. The same issue arises when a headline changes: the article markup should follow the headline of the work people are reading, while the organization name remains the organization name.
This approach has a cost. Editors or the publishing system must keep the headline, byline, and dates consistent across the visible article and its structured description. Yet this is cheaper than building an elaborate article template that produces convincing but inaccurate data. Where the page has no reliable author or publication record, I would fix that editorial record first. Schema is strongest when it mirrors a publication process that already knows what was published, by whom, and when.
Use breadcrumbs to describe a route people can follow
A breadcrumb trail answers a third question: where does this page sit in the site hierarchy? Google’s breadcrumb guidance describes a trail as the page’s position within that hierarchy. Its ordered items can carry names and destination URLs. This is about navigation, not authorship or ownership. If a visitor can move from a section to a subsection and then to the current page, the breadcrumb can express that route.
For an illustrative site, imagine the visible path “Guides › Publishing › Site Schema.” The useful markup would preserve that order and point the earlier steps to their actual destinations. It would not add an impressive sounding category that has no usable destination or place the article under a section merely because that section contains a target keyword. Google’s breadcrumb documentation defines the ordered trail; the publisher must supply a route that matches the site people can use.
A breadcrumb also has a narrower role than the article URL. It tells a visitor how the page fits into a hierarchy; it does not settle the page’s canonical identity. If the same article is reachable from more than one route, the site must still be clear about the article itself. I would choose a trail that reflects genuine navigation and let the page’s own identity remain a separate decision. Treating a breadcrumb as a replacement for that identity asks a navigation label to do a job it was not designed to do.
The trade-off becomes visible during site reorganizations. Moving an article from one section to another may require a new visible trail and a new structured trail. Keeping an old breadcrumb can send readers toward a section that no longer explains where the article lives. If the site has no meaningful hierarchy beyond a home page and an article, there is little reason to invent intermediate levels just to make a longer trail. The best breadcrumb is the shortest accurate route that the site actually offers.
Choose terms for the page and the intended search feature
Schema.org and Google Search play different roles. Schema.org defines a vocabulary that can describe many kinds of entities and relationships. Google’s structured-data guidance documents the features and formats it supports in Search. A term’s existence in the vocabulary therefore does not mean that adding it makes a page eligible for a particular Google display. That gap explains why “the schema is valid” is not a complete answer to “will this change our search result?”
I would make two decisions in sequence. First, decide what the page truthfully describes. Second, if a particular Google Search presentation is the aim, read the guidance for that supported feature and use properties that apply to the page. This order prevents a search appearance goal from dictating facts. An article does not acquire an author because a markup example has an author field; the published work must actually have an author to name. A navigation path does not become real because a breadcrumb format allows ordered items.
The distinction also limits how much work to do. The larger Schema.org vocabulary may be useful in other contexts, but adding fields solely because they exist can increase the number of values a publisher must maintain. If the page already has a clear organization name, article information, and navigation, those are a sensible first scope. A more specialized type or property deserves attention when it describes real content and serves a specific use, not when it simply makes the code look comprehensive.
Keep the format maintainable and the claims modest
The content decisions come before encoding, but encoding still has to fit the site. Schema.org vocabulary can be written in formats including JSON-LD, Microdata, and RDFa. Google’s structured-data introduction discusses supported formats and the difference between its Search guidance and the wider vocabulary. For a site owner, I would choose the format the publishing setup can reliably update. A technically elegant block that editors cannot keep synchronized with the page will age badly.
The most useful maintenance question is concrete: when the article headline, author, date, organization logo, or navigation changes, what updates the corresponding markup? If the answer is “someone will remember to edit a separate block,” the site is likely to accumulate mismatches. Connecting each value to the page information it describes is a sounder editorial design. It still needs care: a shared template should use shared organization details, while an article template should read that article’s own fields.
It is reasonable to check a representative home page and article page after implementing markup, then revisit pages when templates or publishing practices change. Compare the rendered page with its structured description: is the organization named correctly, does the article carry its own headline and dates, and does the breadcrumb lead through usable sections? Those questions test the meaning of the data, which a syntactically correct snippet alone cannot establish. A mismatch is worth fixing even if no search feature has visibly changed, because the mismatch is already an inaccurate description of the site.
The outcome should be described modestly. Structured data makes page information machine readable and can support search features where the page meets the relevant guidance; Google’s introduction does not promise a special result for every marked page. I would judge a site schema project first by whether it accurately describes the organization, each article, and the real navigation. Search appearance is a possible consequence under the search provider’s rules, not the fact that makes the description worth maintaining.
Start with a small set of true descriptions
For a publication deciding what to do next, I would start at the home page and one typical article. Write down the organization name, website URL, and logo the home page actually presents. On the article, identify the published headline, named author, original publication date, any real later modification, and the path a visitor can follow through the site. Then map those facts to Organization, Article, and Breadcrumb markup as applicable. The corresponding Organization, Article, and breadcrumb guidance supplies the relevant property context.
That small start exposes the difficult decisions early. If the organization has several competing names, decide which entity the site represents. If the article has no dependable byline or dates, repair the publishing record. If the breadcrumb points through a section visitors cannot use, repair the route. Once those facts are stable, extending the same approach to other pages is straightforward in principle, though every page still needs its own values. The goal is a set of descriptions that remain true as the site grows, rather than the longest possible list of schema properties.