Hotel Schema Basics (No Duplicate JSON-LD)

What schema should do for hospitality sites

Schema should clarify what a page is (WebPage/Service/Article), how it relates to your organization, and how pages connect in your site structure. The goal is not to ‘add schema everywhere’; the goal is to reduce ambiguity so search engines understand intent and relationships consistently across the site.

The safe baseline: one breadcrumb + one primary schema

Start with the minimum that stays correct across a large site. For most indexable pages, the safe baseline is exactly one breadcrumb schema plus one primary schema that matches page intent. Avoid adding multiple primary schemas or repeated breadcrumb scripts; duplicates are one of the most common causes of schema warnings and rich-result volatility.

Pick the right primary schema for the page intent

The primary schema should match what the page actually is. A service landing page is different from an informational guide, and both are different from a tool. Don’t force Service schema onto everything. For most informational pages, WebPage schema is the safest primary type. Use more specific types only when they reflect visible content and the page intent.

• Service pages: only when the page is clearly a service offering and contains unique service information
• Articles/blog: use Article schema when it is a true article and the content supports it
• Tools: consider application-style schema when the page is clearly a tool experience
• Playbooks/resources: WebPage schema is typically the safest default

FAQ schema: only when FAQs exist (and only once)

Only include FAQ schema when FAQs are visibly present on the page. If FAQs are not rendered, do not output FAQ schema. Also ensure it appears once: duplicates happen when both a shared component and a page-level script inject FAQ JSON-LD. Duplicated FAQ schema is a common error and can trigger warnings even if the content is otherwise correct.

Breadcrumb schema: don’t double-inject

Breadcrumb schema is frequently duplicated because teams add it in multiple places: a breadcrumb UI component and a page-level schema component. Choose a single owner. If your UI breadcrumb component injects breadcrumb schema, page-level JSON-LD should not add it again. This is one of the easiest rules to enforce at scale, and it prevents a high-volume class of schema duplication bugs.

Entity linking (Organization and WebSite) for consistency

Use stable Organization and WebSite entities site-wide and link page schemas back to them. This creates consistent entity anchors and reduces ambiguity when the site has many page templates. Keep the entity IDs stable and ensure the canonical domain and URLs are consistent across the site.

Common schema pitfalls on hospitality sites

Schema regressions usually happen during refactors, redesigns, or when new components are introduced without clear ownership. Treat schema like a governed system, not a one-time task.

• Multiple breadcrumb scripts on a single page
• FAQ schema output without visible FAQs
• Mismatched page intent vs schema type
• Inconsistent URLs between schema and canonicals
• Adding schema on noindex pages without considering duplication rules

Verification: validate rendered HTML, not just code

Schema must be validated in the rendered output. Review the final HTML for JSON-LD scripts and confirm you have one breadcrumb schema, one primary schema, and at most one FAQ schema (only if FAQs exist). Use automated audits to catch duplicates and regressions before deployment.

Monitoring and governance as the site scales

As you publish more pages, governance matters more than individual schema tweaks. Make schema rules enforceable with audits against rendered HTML, and ensure new templates can’t accidentally output duplicates. The most scalable approach is a single schema system with clear ownership boundaries per page type.