The Powersports Schema Cookbook: JSON-LD for Vehicle, Offer, LocalBusiness, and Organization Markup
Rowan MocklerCofounder, CEO
Apr 15, 2026 · 10 min read
AI summary
Copy-paste JSON-LD templates for motorcycles, UTVs, ATVs, snowmobiles, and PWC inventory, plus location pages, organization markup, and the validation steps that catch the errors most provider templates ship with. Part of our Powersports Website Playbook.
If there's one investment that pays for itself faster than any other on a powersports dealer website in 2026, it's getting structured data right. AI search engines retrieve schema first because it's parseable and unambiguous. Google's rich results, AI Overviews, voice assistants, and the next round of vertical-specialized retrieval surfaces all draw from the same structured-data graph.
Powersports inventory sits in a complicated zone of Schema.org types. There is no universally adopted Powersports, UTV, or ATV type. The good news: the available types, Vehicle, MotorizedVehicle, Product, Offer, LocalBusiness, AutoDealer, Organization, cover what you need if you implement them correctly.
This cookbook is a working set of JSON-LD blocks you can drop into your VDPs, location pages, and homepage, plus the validation workflow and the most common implementation mistakes that get otherwise-good schema partially or fully ignored.
How schema works on a dealer website (the 60-second version)
Every public page on the site renders a block in the head or before the closing
tag. The block contains structured data describing what's on the page, a vehicle, a category, a location, the dealership itself. Search engines and AI systems parse that block and treat it as a high-confidence summary of the page's content.
Schema doesn't replace the visible content. It restates it in a structured form. When the two contradict, the page says 168 horsepower but the schema says 999, the engine treats the source as untrustworthy. Mismatches are one of the most common, and most damaging, schema problems on dealer sites.
The four schema blocks every powersports dealer site needs:
Vehicle / MotorizedVehicle on every VDP. Inventory unit, with nested Offer for price and availability.
ItemList or CollectionPage on every category SRP. Listing of vehicles in the category, with optional Vehicle items embedded.
LocalBusiness or AutoDealer on every location page. Dealership physical location, hours, NAP, services.
Organization on the homepage. Brand-level entity, logo, social profiles, sameAs links to OEM relationships.
VDP schema: the working JSON-LD block for a UTV
Drop this in in the head of your VDPs. Replace the bracketed values with real data from your inventory feed.
Motorcycles. Swap "@type": "Vehicle" for "@type": "MotorizedVehicle". Set vehicleConfiguration to the motorcycle segment, "Sport Motorcycle", "Cruiser Motorcycle", "Sport Touring Motorcycle", "Adventure Motorcycle", "Dual Sport Motorcycle", "Standard Motorcycle". Drop seatingCapacity (or set to 1 or 2 as appropriate). Engine displacement units stay CMQ (cubic centimeters).
ATVs. Stick with "@type": "Vehicle". Set vehicleConfiguration to "ATV" or "Sport ATV" / "Utility ATV" / "Youth ATV". Drop or adjust seatingCapacity to 1 or 2 depending on the unit.
Snowmobiles. Use "@type": "Vehicle". Set vehicleConfiguration to the segment, "Trail Snowmobile", "Mountain Snowmobile", "Crossover Snowmobile", "Touring Snowmobile", "Utility Snowmobile". Drop mileageFromOdometer and replace with vehicleEngine and use-case-relevant fields. Some dealers add a custom additionalProperty for engine type (2-stroke vs. 4-stroke).
Personal watercraft. Use "@type": "Vehicle". Set vehicleConfiguration to "Personal Watercraft" with sub-segment in the name (Recreational, Performance, Luxury, Tow-sports). Drop mileageFromOdometer; keep engine, seating, color.
Used vs. new units
For used units, set mileageFromOdometer to actual hours or miles. Add "itemCondition": "https://schema.org/UsedCondition" to the nested Offer. New units use "itemCondition": "https://schema.org/NewCondition". CPO (where the OEM has a CPO program) uses "itemCondition": "https://schema.org/RefurbishedCondition" plus a manufacturer warranty reference if available.
Sold or out-of-stock units
When a unit sells, the right move depends on your sold-unit hygiene strategy (see inventory feed enrichment and sold-unit hygiene for the full decision tree). If the page persists, the Offer.availability flips:
"availability": "https://schema.org/OutOfStock" for units sold but page persisted.
"availability": "https://schema.org/Discontinued" for units no longer available and not coming back.
Page removed entirely with HTTP 410 (Gone) for units where you don't want long-tail traffic on the URL.
SRP schema: ItemList for category pages
Category pages, "2026 Motorcycles for Sale,""UTVs and Side-by-Sides,""Used Snowmobiles in [State]", should render an ItemList with each visible listing as an item. Two structures work; pick based on listing count:
For up to ~30 listings, embed the full Vehicle data on each item. Each engine that hits the SRP gets the full inventory snapshot in one parse.
If you operate multiple physical locations, each gets its own location page with its own AutoDealer block, same name (or location-suffixed name), location-specific NAP, location-specific hours. The homepage Organization schema references all of them via subOrganization or by listing them as location entries.
Organization schema for the homepage
The homepage gets Organization schema describing the dealership entity at the brand level. This is what lets engines disambiguate "[Brand] dealer in [City]", the entity graph that ties the brand, the locations, and the OEM relationships together.
The brand array is what tells AI engines which OEM relationships you carry, material when buyers ask "where can I buy [Brand]" queries.
Audit what schema your site is actually emitting
Before you start writing new JSON-LD, find out what your current site is shipping. Most provider templates emit incomplete or invalid schema, and the rendered HTML doesn't always match the template documentation. The Website Grader inspects the structured data on any dealer page, flags what's missing or malformed, and runs an AI-search visibility check alongside it, a faster first pass than crawling your own site by hand.
Validation: the workflow that catches errors before they ship
Validate every schema block before it goes live. Two free tools, used together:
Google Rich Results Test (search.google.com/test/rich-results). Tests whether the schema is eligible for Google rich-result features. Catches syntax errors, missing required fields, and Google-specific issues. Returns "Eligible for rich results" or a list of errors and warnings.
Schema.org Validator (validator.schema.org). Tests whether the schema conforms to the underlying Schema.org spec. Catches structural issues that Google's tool may not flag.
Run both on every page type, VDP, SRP, location page, homepage, on every release. Errors are disqualifying. Warnings degrade citation eligibility but don't necessarily block rich results.
For ongoing monitoring, Google Search Console reports structured-data errors detected during crawl. Set up email alerts on the structured-data report.
The seven mistakes that show up most often
1. Schema doesn't match visible content. The page says "168 horsepower," the schema says 999. Buyers see one, engines see the other. Engines treat this as a signal to discount the source.
2. availability is stale. Unit sold three weeks ago, schema still says InStock. AI engines that cite the page get burned and down-weight the entire source. (See inventory feed enrichment and sold-unit hygiene for the fix.)
3. Missing nested Offer.Vehicle schema with no nested Offer means no price, no availability, no rich-result eligibility, no inventory in AI Overviews.
4. seller block missing or generic. The Offer.seller should be a fully populated AutoDealer block with the dealership's NAP. A generic Organization block, or no seller at all, leaves the engine with no entity to attribute the listing to.
5. Multiple conflicting blocks on the same page. Some provider templates render two Vehicle blocks (one from the template, one from a plugin), each with different data. The engine sees contradictory information and trusts neither.
6. image array points to placeholder or stock images. Pages with image arrays pointing to /assets/placeholder.jpg or shared OEM stock URLs get down-weighted. The image array should be unique per unit and point to actual rendered images on a CDN.
7. NAP in schema doesn't match GBP and citation directories. The street address in schema reads "123 Main St, Suite 200" but the GBP listing reads "123 Main Street Ste 200". Engines use NAP-matching to confirm entity identity. Even minor inconsistencies degrade local entity confidence.
What to ask your website provider
Three questions:
Show me a live VDP's structured data, validated in both Google's Rich Results Test and the Schema.org validator. What does the Vehicle schema include, and how is availability updated? The right answer is "live, the moment a unit sells", not "nightly" or "by the next crawl."
How does schema render on category SRPs and location pages? Show me a live example of each. If they don't render schema on SRPs and location pages, you're leaving rich-result eligibility on the table for category and local-intent queries.
What's your validation workflow on every release? Automated validation in CI, or alerts in Search Console, not "we check it manually when something breaks."
If schema is described in marketing terms ("we're SEO-optimized") rather than technical terms (validated, real-time, audited), that's the answer.
This cookbook is part of our Powersports Website Playbook, the full strategic frame, audit, 90-day plan, and provider questions for ranking and getting cited by AI search in 2026.
Frequently asked questions
Use <code>"@type": "Vehicle"</code> with <code>vehicleConfiguration: "UTV / Side-by-Side"</code>. There is no dedicated <code>UTV</code> Schema.org type, so <code>Vehicle</code> plus a descriptive <code>vehicleConfiguration</code> value is the correct approach. Nest a fully-populated <code>Offer</code> block with <code>price</code>, <code>priceCurrency</code>, <code>availability</code>, and a complete <code>seller</code> block.
In real time, not nightly. AI search engines pull source data at query time and punish sources that say "InStock" for units that are actually sold. The right pattern is event-driven: when the inventory system marks a unit sold, the page either flips its <code>availability</code> to <code>OutOfStock</code> (or <code>Discontinued</code>) or returns HTTP 410 within minutes, not hours.
You use the same parent type (<code>Vehicle</code> or <code>MotorizedVehicle</code> for motorcycles) but adapt <code>vehicleConfiguration</code>, drop irrelevant fields (e.g., <code>mileageFromOdometer</code> for snowmobiles, <code>seatingCapacity</code> for solo motorcycles), and add segment-appropriate engine fields. The structure stays consistent; the values change per segment.
JSON-LD in a <code><script type="application/ld+json"></code> block is the recommended format. Microdata and RDFa are supported by Schema.org but harder to maintain and more error-prone. JSON-LD also keeps structured data separate from the visible markup, which makes it easier to validate and update independently.
Schema that says one thing and visible content that says another, different horsepower, different price, different availability. Engines treat these mismatches as a signal to discount the entire source. The fix is a single canonical source per attribute (typically the inventory feed) feeding both the schema and the visible content, with no separate human-edited path that can drift.
Run every page type, VDP, SRP, location page, homepage, through Google's Rich Results Test and the Schema.org Validator. Errors are disqualifying; fix them before shipping. Warnings degrade citation eligibility but may not block rich results. For ongoing monitoring, watch the Structured Data report in Google Search Console and set up email alerts on new errors detected at crawl.