Schema markup should describe the page and business accurately, remain consistent with visible content and survive routine website updates. Adding more schema types is not a useful goal on its own. In this guide, we explain the implementation decisions we would make for a Hong Kong service website, the checks that reveal common mistakes and the evidence needed before calling the work complete. The examples describe a practical review process, not a claimed ranking experiment.
TL;DR: Get the meaning right before adding code
- Choose markup that matches the real business and the actual purpose of each page.
- Check existing theme and plugin output before adding a second implementation.
- Validate syntax, factual accuracy and live output separately.
- Do not promise rankings, rich results or AI citations because a test passes.
Map the facts before selecting the schema
We begin with the business name, locations, contact details, relevant people and the pages that describe them. Those facts should agree with the website. An office move, a new telephone number or an outdated author profile can make technically valid markup misleading.
For a hypothetical Central professional services firm, we would distinguish the company, its office, its services and its articles. They are related entities, but not interchangeable descriptions of the same thing. A service guide should not pretend to be a product available for purchase if the business does not sell it that way.
| Page or entity | Markup to consider | Practical check |
|---|---|---|
| The company | Organization | Use its real identity and consistent details |
| A physical business location | LocalBusiness or an appropriate subtype | Check the address, contact details and relevant opening hours |
| An editorial article | Article or BlogPosting | Match the actual headline, author and publication information |
| Page hierarchy | BreadcrumbList | Represent a useful navigation path |
This is a selection guide, not an instruction to place every type on every page. Our structured data overview explains the broader purpose; implementation starts with the narrower question of which facts this page needs to communicate.
Inspect existing output before adding another plugin
A WordPress site may already generate structured data through its SEO plugin, theme or page builder. Before installing another schema tool, we inspect what the live page actually outputs.
- Identify each component generating markup.
- Look for duplicated entities with conflicting names, addresses or authors.
- Check whether related nodes refer to the intended entity.
- Choose a clear owner for each part of the implementation.
- Remove or correct conflicts through the component that generates them.
Multiple script blocks are not automatically an error. A separate article node and organisation node may be appropriate. The problem is contradictory or disconnected information, such as two company descriptions pointing to different addresses. Deleting markup simply because there is more than one block can remove useful context.
Validate three different things
We treat validation as three checks. First, does the code parse and use the vocabulary correctly? Second, does it describe the real page accurately? Third, where a supported search feature is relevant, does it meet that feature’s current requirements?
A validator cannot confirm that a named author wrote an article or that a business actually trades from the address in its markup. Those are editorial checks. Similarly, a valid vocabulary type does not automatically qualify for a Google rich result. Search feature support and requirements must be checked at implementation time.
For example, a business might copy review ratings into its company markup because it wants stars in search. We would first check review eligibility, where the reviews come from and whether the feature supports that use. We would not assume a visible testimonial creates eligibility for a review rich result.
Three checks before sign off
Can the markup be read correctly?
Does it match the actual page and business?
Does the intended feature support this use?
Check both languages on bilingual websites
For an English and Traditional Chinese website, the article headline and description should reflect the relevant language version. The business should still have a consistent identity across both pages. We check that page references, images, authors and dates correspond to the actual document.
Structured data does not replace language association, canonical URLs or hreflang. A Chinese article pointing to an unrelated English page still has a relationship problem, even when its schema parses correctly. Our bilingual GEO guide covers the wider content and language considerations.
Verify the published page, then maintain it
The editor preview is not the final output. Caching, templates and plugin settings can change what reaches the public page. After release, we inspect a representative live URL, confirm the intended information appears and check that unwanted conflicts have gone.
We then revisit markup when a change affects its facts or generation method. That includes an office move, author update, redesign or SEO plugin replacement. Where search reporting is available, we monitor relevant errors and eligibility separately from rankings and enquiries.
There is no special schema required to enter Google AI Overviews or AI Mode. We would not sell schema markup as a guaranteed route into AI answers. It supports a coherent website implementation alongside accessible content, credible information and wider SEO work. Our GEO services address AI visibility as a broader task.
A quick implementation check
Choose one important article or service page. Compare its visible business details with its structured data, then identify which website component creates that markup. If you cannot tell who maintains the information, resolve that ownership before adding more code. Accurate data with a clear maintenance process is a better starting point than a larger collection of unchecked schema types.
Frequently asked questions
Should schema changes be tested on a staging website first?
We would use staging to check template changes and confirm that the intended markup is generated before release. Staging should remain separate from the public search presence, and its test URLs should not accidentally remain in production output. After deployment, we would validate the public page again because staging success does not confirm the live configuration.
Do we need to inspect every page after changing a schema template?
We would sample each affected page type and include exceptions, such as articles with different authors or locations with different opening hours. For a larger site, automated checks can help identify missing or inconsistent fields across URLs. One successful article does not establish that every template or language version is correct.
What should we do when schema contains an incorrect business fact?
We would correct the source generating that fact, then inspect the live output and any relevant cache. If an optional field cannot be supported accurately, we would remove it until it can be verified. Adding another script with the right value can leave the original contradiction in place.
Should we use manually written schema or a CMS template?
We would choose based on how often the information changes and who will maintain it. A reusable template can keep common page types consistent, while manual code may suit a specific case that needs careful control. Either approach needs a named owner and checks that updates to visible content also reach the markup.
