Web pages, websites and breadcrumbs
WebPage, WebSite and Breadcrumbs: Describe a Page in Its Site
Identify the page, the website it belongs to and the route a reader can use to recover context. Keep these identities separate from the subject described on the page.
Free learning from Semantec SEO.
Separate the page, site and subject.
A WebPage is an individual web resource. A WebSite is the related collection of pages. An organization publishing the site is another entity again. Giving all three the same name does not make them the same thing. A useful graph records their relationships rather than collapsing every node into the business.
WebPage and WebSite provide the vocabulary for those roles. Use isPartOf to connect a page with its site. Keep url for the public address and an agreed stable @id for the graph identity; a fragment such as #webpage identifies a node, not a second indexable page.
Begin with the approved canonical URL, visible title, language, page purpose and current template output. Inspect existing plugin nodes before adding another block. Two generators describing one URL with conflicting names or identities create a maintenance problem that more markup will not resolve.
Describe the main subject without inventing one.
mainEntity identifies the entity chiefly described by a creative work. On a page dedicated to one service, it can point to that service. about records subject areas and can cover topics discussed without claiming each is the defining subject.
A collection of equally prominent resources may not have one business entity as its focus. Do not assign the publisher as mainEntity merely because the publisher owns the domain. Distinguish an editorial article node, the WebPage containing it and the entities discussed in the article.
Choose a more specific page subtype only when its meaning fits the visible role. A directory may fit CollectionPage; a profile may fit ProfilePage. Check the applicable type and consumer documentation rather than using a subtype to seek an unrelated search feature.
Make the breadcrumb a useful route.
A breadcrumb expresses a sensible place in the website hierarchy, not the visitor’s click history. Its labels should help a reader understand where the page belongs and move to an appropriate parent. A URL folder pattern is useful evidence, but it need not be the whole navigation model.
Keep the visible trail, linked destinations and BreadcrumbList consistent. Each ListItem needs its order and label, with the appropriate destination. Use approved canonical URLs, avoid invented parent pages and keep the current-page label understandable even when it is not a link. In Google’s BreadcrumbList requirements, the final item’s destination may be omitted; do not mistake that exception for permission to omit the preceding hierarchy.
Google documents Breadcrumb structured data as a separate feature with its own requirements. WebPage alone is not that feature. Accurate hierarchy does not guarantee any particular presentation. Different truthful trails can be possible, but an arbitrary list of keywords is not a breadcrumb.
Worked map: a topic page and its trail.
Consider a fictional teaching site at example.com. Its visible resource, “Choosing a bicycle service”, belongs under a Guides directory and explains how to choose a service; it is not the provider’s offer. The following addresses and titles are invented planning records, not live pages or deployed markup.
The visible trail is Home → Guides → Choosing a bicycle service. The Home and Guides items link to their corresponding pages. The final item identifies the current resource. The site node is example.com/#website; the page node is example.com/guides/bicycle-service/#webpage.
The page’s isPartOf points to the site node and breadcrumb points to its #breadcrumb node. Its about can name bicycle servicing as a topic. If an Article node describes the resource itself, connect it with mainEntityOfPage to the page identity; do not invent a particular repair provider as the resource’s main entity.
The map passes a planning check only if the approved page content and navigation support it. Before production, resolve the observed canonical addresses, existing nodes, article identity and labels, then test the combined output.
| Record | Teaching decision | Visible support or check |
|---|---|---|
| WebSite | https://example.com/#website | Whole related site, not the publisher identity |
| WebPage | https://example.com/guides/bicycle-service/#webpage | One resource with its canonical public URL |
| Trail item 1 | Home → https://example.com/ | Working home navigation |
| Trail item 2 | Guides → https://example.com/guides/ | Real parent directory |
| Trail item 3 | Choosing a bicycle service | Current resource, position 3 |
| Subject | Bicycle servicing; optional separate Article node | Resource content, not an invented business offer |
Check the complete rendered page.
Compare the source graph and rendered graph with the title, body, breadcrumbs and canonical. A syntactically correct node can still point to the wrong parent or describe an obsolete page. Use a vocabulary validator for meaning and structure, and the relevant platform test for a supported feature.
Inspect mobile navigation as well as desktop. A breadcrumb must not depend on unreadable labels or inaccessible controls. Structured data does not replace ordinary links, headings or a useful parent hub. Keep navigation understandable when no search enhancement appears.
When a page moves, update canonical relationships, breadcrumb destinations and incoming links together. Preserve stable entity identities where the entity remains the same, while correcting page-specific addresses. Record the change, responsible template owner and validation result.
Keep identity and navigation maintainable.
Keep a small record of page role, canonical, page ID, site ID, subject decision, breadcrumb labels, evidence and responsible owner. Missing canonical or unclear subject is a reason to hold that assertion, not to fill a plausible entry.
Return to the structured data overview or learning overview. Use the Schema.org data model to check type/property relationships and Google’s structured data introduction for the distinction between description and search features.