Describe the page before choosing a type
Open the public page and write one sentence describing what a visitor can actually find there. Separate the main subject from navigation, promotional panels and related links. A tutorial mentioning software is not automatically the software’s product page, and a company logo does not make every page primarily an organization profile.
Save the URL, a dated content snapshot and the existing markup. Identify which part comes from the theme, a plugin or custom code before requesting changes. This inventory helps avoid adding a second description of the same item without understanding the first.
Map properties to visible evidence
Create a small mapping with four columns: proposed type, proposed property, supporting page content and source owner. For an article, this might link its headline to the displayed heading and its author to the credited author. Leave unavailable information unresolved instead of filling a field with plausible text.
Google’s general guidelines require structured data to represent the page and prohibit irrelevant or misleading content. Choose the most specific applicable type, then read its current feature documentation. Do not select a type solely because its search appearance looks attractive or a plugin offers a convenient preset.
Separate vocabulary from search support
Check whether the intended Google feature supports the chosen type and what its documentation requires. A term existing in a vocabulary does not by itself establish eligibility for a particular search feature. Record the documentation URL and check date alongside the decision so later reviewers can revisit it.
If the page lacks a genuine required fact, ask whether that feature is appropriate at all. Do not manufacture an offer, rating or event to satisfy a validator. A page can remain useful to readers even when it cannot support the desired enhanced appearance. Technical correctness and editorial truth are separate review questions.
Illustrative example: a guide about a scheduling app
Imagine a fictional page that teaches readers how to organize appointments. It contains an explanatory article and a link to a separate application page. The editor evaluates article markup for the guide because the visible material is editorial; the mention of an application does not justify describing the guide itself as that application.
The review record lists the headline, credited author and real dates available on the guide. Application-specific facts are evaluated on the separate application page. This example illustrates scope selection, not a promise that either page will receive a rich result. If the guide later becomes a different kind of page, its markup needs another review.
Approve the mapping before implementation
Have the content owner confirm the evidence map before a developer implements it. Test the resulting markup and inspect the public rendered content together. Check that deployment has not retained an outdated block elsewhere on the page, and that every described item still has the intended relationship to the main subject.
Keep the chosen type, rejected alternatives and reason in a brief change record. Google does not guarantee enhanced display even for correct markup. Use a website audit to identify pages needing review, then use the evidence map to decide what those pages can honestly describe. Revisit that decision when the visible content changes.