Schema.org markup should describe the information a visitor can actually see. In WordPress, inspect existing markup, map types to page templates and validate the deployed output. Structured data can support interpretation and eligible search features; it does not guarantee an AI recommendation or citation.
1. Identify the markup owner
Inspect the source of a product page, an article and your company page. Locate application/ld+json and determine whether the theme, an SEO plugin, WooCommerce or custom code generates it. Several connected objects are legitimate. Conflicting values for the same entity are the problem. Avoid disabling every block before understanding its purpose.
2. Map types to templates
| Page | Type to consider | Acceptance check |
|---|---|---|
| Company information | Organization | Consistent name, URL and identity |
| Editorial article | Article or BlogPosting | Accurate author, headline and dates |
| Product | Product with an applicable offer | Current price, currency and availability |
| Navigation | BreadcrumbList | Matches the visible navigation path |
Do not fabricate reviews, ratings or availability. Write FAQs for readers first: Google retired FAQ rich results in May 2026; FAQPage no longer provides that feature in Google Search. Consult the documentation for the particular search feature before configuring its properties.
3. Choose a reliable data source
Generate price and availability from product data instead of maintaining a second manual copy. Use stable @id values to connect entities. Use sameAs for appropriate official identity references. Back up settings before changing plugins and test on a staging copy. If your theme and plugin describe the same product inconsistently, resolve the conflict at the source.
4. Validate the deployed page
Check the actual page source, Google's Rich Results Test and the Schema.org validator. Invalid syntax, missing feature-specific properties and disagreement with visible text are separate issues. Test a product variant, a product without reviews and an unavailable product. Record the checked URLs and the change made; a validation pass is not evidence of a business outcome.
5. Separate implementation from AI observation
Validation confirms markup quality, not a model's future response. Semly's monitoring provides a separate way to observe brand presence and context in AI answers. Keep a technical change log so later observations are not automatically attributed to schema alone.
Release checklist
- Markup matches the visible content.
- Offer information updates with the product.
- Theme and plugin data do not conflict.
- Relevant validators show no unresolved errors.
- Theme or plugin updates trigger another check.
Google does not require special schema for AI Overviews or AI Mode. Crawlable pages, useful content and consistent facts remain the foundation.
A fictional acceptance scenario
The following is a proposed QA record for an imaginary store. It is not a completed test or a company measurement.
| Observed state | Decision | Correction |
|---|---|---|
| Selected variant has a different price from JSON-LD | Do not release | Generate the offer from the displayed variant |
| Page says unavailable while markup says in stock | Do not release | Use the same product record for availability |
| Product has no reviews but code includes a rating | Do not release | Remove the unsupported rating |
| Two descriptions of one company use different names | Check identity | Reconcile the entity and its stable identifier |
Apply the check to individual templates, not just the homepage. For each fix, record the URL, template owner and prevention rule. This turns a one-off validator pass into a maintenance procedure.
Sources and preparation
AI assisted with organizing this procedure. References were checked against public documentation on 3 October 2026. This is implementation guidance, not a company-results report or a test of ranking impact.
