Your website tells shoppers what you have for sale, what it costs and where to find you. It also supplies information to software, including search engines and tools that read inventory pages. The facts that software reads need the same care as the listing a customer sees.
Schema is a way to label those facts in your website's code using names that different systems recognize. It is also called structured data or markup. Think of it as a labeled vehicle record: this is the VIN, this is the asking price in U.S. dollars, this is the mileage in miles, and this is the dealership selling it. Google says it uses structured data to help understand page content. Google's explanation
A person can use a page's layout and headings to distinguish a purchase price from a monthly payment. Explicit labels give software a way to make that distinction without relying only on where a number appears or how the page is designed.
Why schema matters to a dealership
Consider an illustrative request: “Find me a used SUV under $30,000 with fewer than 50,000 miles.” An agent checking your inventory needs to establish the vehicle's condition, price and mileage before it can say the vehicle fits. It also needs to know which specific vehicle the facts describe and whether it is still offered for sale.
When a tool reads schema, those labeled fields can supply the facts it needs for that comparison. If the mileage field is empty, the tool cannot confirm the mileage limit from that record alone. If the price is actually a monthly payment labeled as a purchase price, the record gives the tool a false reason to include the vehicle. A tool might find the right facts elsewhere on the page, but the structured record has not done its job.
That is why “our site has schema” is only the starting point. Useful schema needs to describe the correct vehicle, include the details needed for the question, and keep them accurate as inventory changes. A missing field leaves a question unanswered. A wrong field supplies a wrong answer.
For the dealership, the practical purpose is to help software using these records compare the right vehicles, describe offers correctly and connect them to the right store. Each tool decides which information it reads and uses. This study did not measure whether a particular search engine or AI agent recommended a vehicle or generated a lead.
What we found
All 1,458 sampled vehicle detail pages contained Schema.org Vehicle or Car markup, both before and after JavaScript ran. In other words, every sampled vehicle page supplied a labeled vehicle record. That is a useful foundation. We then checked which details those records contained and whether reviewed values agreed with the shopper's page.
Mileage markup was missing on 165 of 501 evaluable used-vehicle pages (32.9%), compared with 445 of 954 new-vehicle pages (46.6%). New vehicles account for much of the overall gap, but they do not explain it all. One used and two new pages were unknown and were excluded from those denominators. Missing mileage markup does not necessarily mean the shopper's page omitted mileage.
On 162 of 486 homepages—one-third—the first recognized schema appeared only after the browser ran JavaScript, code that builds or updates a page. A tool reading only the website's initial response would not receive those later-added facts in its schema record. It could still encounter information elsewhere in the page. Study data, new/used mileage breakdown
These are observations from the completed sample, not national dealership estimates.
What we examined
We selected one homepage, one page listing vehicles and three pages devoted to individual vehicles per website. We included new and used vehicles wherever our search procedure found both. The completed sample covers 486 websites in 39 states: 125 in the Midwest, 125 in the Northeast, 124 in the South and 112 in the West.
We tested the process on 20 websites before fixing the main collection and selection rules. Limits on regions, states, dealer groups, manufacturer families and identified website providers kept the sample from becoming too concentrated in one group. A fixed selection rule chose vehicles, rather than a reviewer choosing the most interesting examples. Later corrections to the analysis were documented. The original evidence and code versions are retained privately.
Our target was 500 websites. We attempted 817 candidates and included 486 after each supplied five usable pages and passed the inclusion checks. The other attempts included 248 unavailable homepages, 39 cases where we could not finish finding inventory pages, 37 without enough distinct vehicle-page candidates, and seven captured sites excluded or left unusable after review. We ended collection after the final replacement queue, with additional candidates still unattempted. The reported sample is 486, not 500. Methodology, sampling log
Why this matters: A homepage check cannot tell you whether individual vehicles are described properly. Sampling inventory and vehicle pages exposes different parts of the same website. The access limits also matter: these results describe the sites we could complete, rather than every U.S. dealership.
Which details were filled in—and why each one helps
Each detail answers a different question. A VIN identifies the specific vehicle. Mileage describes how much it has been driven. Price and currency describe an amount of money. Having one does not answer the questions covered by the others. Schema.org provides separate fields for these facts. Vehicle field definitions
We checked the vehicle being advertised on each page. Information about another car in a “you might also like” section could not fill its missing details. A separate check of the saved page code found a vehicle record carrying the primary VIN on all 1,458 detail pages.
VIN, make, model and model year appeared as explicit properties on every sampled detail page. Prices, image URLs, condition and availability were also common. Linked seller information, mileage and dedicated trim/configuration appeared less often.
| Detail | Pages with the field / pages we could evaluate | Share | What it helps software establish |
|---|---|---|---|
| VIN, make, model and model year, each | 1,458 / 1,458 | 100.0% | Which vehicle is this? The VIN keeps one stock vehicle's facts separate from another's. |
| Image URL | 1,456 / 1,458 | 99.9% | Which photo belongs with this listing? A wrong link can pair the vehicle with the wrong image. |
| Currency | 1,450 / 1,458 | 99.5% | Which currency is the price in? A number alone does not say U.S. dollars. |
| Condition and availability, each | 1,449 / 1,458 | 99.4% | Is it new or used, and what is its listed sale status? These facts affect whether it fits a request. |
| Price amount | 1,447 / 1,458 | 99.2% | Does the offer fit a budget? The amount must describe the correct price and its terms. |
| Linked seller | 978 / 1,455 | 67.2% | Which dealership is offering this vehicle? A group name elsewhere on the page may not identify that store. |
| Mileage and mileage units, each | 845 / 1,455 | 58.1% | How far has it been driven? Both the reading and miles versus kilometres matter. |
| Trim / configuration | 247 / 1,455 | 17.0% | Which version of the model is it? Different trims can have different equipment and prices. |
Three pages are unknown for seller, mileage, units and trim completeness. These counts tell us whether a field was filled in; they do not certify that its value was correct. We counted a separate trim field, so a trim mentioned only in the vehicle's title did not qualify. We also required a connection between the seller and the vehicle or offer; a dealer name elsewhere on the page was not enough. Field definitions, field-level results
The business details answer equally practical questions: Which store is this? Where is it? How do I contact it? When is it open? The address and map coordinates describe its location. Phone numbers and hours need to refer to the intended store and department. Links to the business's other profiles help connect those profiles to the same business. A wrong number or schedule, if reused by a tool, can give a shopper incorrect contact or visit information. Business field definitions
We could identify the relevant business record on 457 homepages. All 457 included a name, address and phone number. Coordinates appeared on 449 of 457 and links to other business profiles on 372 of 457. These are counts of supplied information. We did not test every phone's routing or verify every department's opening hours.
An optional field can be useful without being required. Missing it does not automatically make the code invalid, but it may leave out a fact needed for a particular comparison. Schema.org data model
What this means: Filling in a field is useful only when it carries the right fact. A correct model paired with the wrong VIN can describe the wrong car. An incorrect trim can misstate the version being offered. Check the field's value, the vehicle or store it belongs to, and whether it still reflects the current listing.
Why accurate values matter as much as filled-in fields
A website can look right to a shopper while supplying a different value in its code. If a tool takes its answer from that code, it can repeat the wrong information even though the visible listing is correct. Fixing the visible text alone does not resolve that disagreement.
Our mileage recheck provides a concrete example. One vehicle advertised as new showed 4,384 miles to shoppers, while its structured record said 0 miles for the same VIN. A fresh capture reproduced both values. A tool using the structured value would describe that vehicle as having zero miles. We verified the disagreement; we did not establish the physical odometer reading. Reviewed example
Zero is a specific claim. It should never be used as a substitute for “we do not know.” The same principle applies to prices and availability: a placeholder price or an outdated “in stock” value can make a record easy to read but inaccurate.
The useful standard is that the visible listing and its structured record describe the same vehicle and offer, using current information. When the price, mileage or sale status changes, check both. Agreement between them is one check; if both contain the same wrong value, the underlying inventory record still needs correction. Google's structured-data guidance also calls for current information that truthfully represents the page. Google's accuracy guidance
Is mileage missing because the vehicles are new?
New inventory made up 956 of the 1,458 vehicle pages, so it strongly affects the combined 58.1% mileage-coverage figure. We split the existing observations by the condition listed on the website:
| Vehicle condition as listed | Mileage markup present | Mileage markup missing | Unknown pages |
|---|---|---|---|
| New | 509 / 954 (53.4%) | 445 / 954 (46.6%) | 2 |
| Used, including certified pre-owned | 336 / 501 (67.1%) | 165 / 501 (32.9%) | 1 |
This additional breakdown was calculated on September 8 using the original September 7 captures. Condition comes from recorded listing labels, breadcrumbs or page titles, not an assumption based on model year. No additional dealerships were collected. Breakdown and methodology
Why this matters for used vehicles: A shopper may use a mileage limit to narrow a search or compare two otherwise similar cars. Without a mileage reading, a tool using only the structured record cannot establish whether the vehicle meets that limit. It should leave the answer unknown or find another source, rather than assume the car qualifies. One audited used-vehicle page displayed 41,639 miles to shoppers but omitted the mileage property from its structured record. The fact was visible; it was missing from the labeled record. Anonymous example and review
Why it can help on new vehicles too: “New” is a condition label, not an odometer reading. Our audit included a vehicle advertised as new with 4,384 miles shown on the page. Publishing the actual known reading helps distinguish a low-mileage new vehicle from one with substantially more use, without asking a shopper or agent to assume that “new” means zero.
Our recommendation is to keep the actual known odometer value and its unit consistent in the visible listing and the structured data for both new and used inventory. Do not fill an unknown reading with zero. This is a recommendation for clearer information, not a claim that Schema.org universally requires mileage on every new car. Its mileage property describes the vehicle's odometer reading. Schema.org's definition
Some website facts appeared only after the browser ran more code
When a website opens, it first sends a page of code called HTML. The browser can then run JavaScript to add or update information. Reading that completed page is called inspecting the rendered page.
We found recognized schema on 299 of 486 homepages in the initial HTML (61.5%), rising to 461 of 486 after the browser ran the page (94.9%). The same 162 homepages account for that increase. Among the remaining 25, 24 had no recognized schema and one contained an attempted declaration with an incorrectly formed type address.
Every selected results page and detail page contained recognized Schema.org entities in both states. The type and content of those declarations could still change. Schema presence by page type
Why this matters: A tool that stops after the first download does not get schema added later. For those 162 homepages, its initial response contained none of the recognized schema records we found in the completed browser view. The dealership's facts might therefore be present in the browser yet absent from the structured information that particular tool reads. The same website can give two tools different amounts of labeled information.
Google can process JavaScript-generated structured data, and it notes that not all bots can run JavaScript. Putting essential facts in the initial HTML can remove that dependency for readers that do not render the page. That is a compatibility consideration, not evidence that these 162 websites lost rankings or were invisible to AI. Our captures did not test individual AI crawlers. Google's JavaScript explanation, structured-data support
Ask your agent to identify which fields arrive in the initial response and which appear later. If important information depends on JavaScript, ask your website provider whether it can also be supplied in the initial HTML and kept consistent with the visible page.
Inventory lists can describe vehicles in different ways
Names of sampled dealerships and website providers are withheld throughout this edition. Provider labels are consistent across the article, charts and data. Comparisons included only supported attributions with at least 20 completed websites. We identified providers from publication credits rather than assuming that a script or image host owned the website implementation. Sixty-seven websites remained unattributed by our recognizer; smaller identified groups are retained in the dataset.
The page showing a list of vehicles is often called a search results page, or SRP. A page devoted to one vehicle is a vehicle detail page, or VDP. A results page can include vehicle records directly, or supply an organized list of links to the detail pages. Schema calls that organized list an ItemList.
All four provider groups below had Vehicle or Car markup on all three sampled detail pages at every included website. Their results pages differed:
| Supported provider | Websites | SRPs declaring Vehicle / Car, initial HTML | SRPs declaring Vehicle / Car, rendered |
|---|---|---|---|
| Provider A | 200 | 200 / 200 | 200 / 200 |
| Provider B | 149 | 1 / 149 | 1 / 149 |
| Provider C | 36 | 36 / 36 | 36 / 36 |
| Provider D | 27 | 0 / 27 | 27 / 27 |
All 149 Provider B results pages carried inventory detail links through ItemList. The single Car-positive page also described model families in an offer catalog; those declarations did not identify individual stock vehicles. Counting the Vehicle type alone would therefore obscure useful inventory links and could confuse model descriptions with stock records.
On all 27 Provider D results pages, Vehicle/Car declarations appeared after rendering. The sample shows implementation patterns associated with providers; it does not establish responsibility for a site's configuration or comparative search performance. Provider chart data, model-catalog review
What this means: The useful question is whether the list leads to the actual vehicles for sale. An agent can potentially follow a detail-page link to get a vehicle's price and mileage, even when the results page does not repeat those facts. A general description of a model family cannot establish which individual units are in stock. Ask your checker to distinguish stock records, stock links and general model descriptions before labeling something missing.
Does the inventory markup cover the vehicles on the page?
We also checked whether results-page markup represented displayed vehicles. In one fully mapped Dealer 732 capture, 15 cards were displayed and 12 ItemList detail links corresponded to the first 12 cards. Three displayed vehicles were not represented in that list. Some cards had sold graphics, so “displayed cards” does not mean “available stock.” A larger site inventory total was not used as the denominator. Anonymous card-to-link summary
Our automated card detector had varying coverage across layouts. We therefore report inspected examples, without claiming an overall inventory-accuracy rate.
Why this matters: A tool that uses only those 12 links as its starting list has three fewer vehicles to inspect than the shopper sees on that page. A vehicle missing from that list cannot be compared through that route. Another tool could find it through ordinary page links or another source. Check that the structured list covers the intended displayed vehicles and points to the right pages; do not assume a site-wide inventory total describes the current page.
Different prices were not automatically wrong prices
A vehicle page can show MSRP, an advertised selling price, a conditional incentive price, a finance payment and a lease payment. Documentation fees can change which amount appears in which place.
At Dealer 550, an apparent $499 difference was explained by the offer description: the $35,125 structured amount excluded a $499 fee, while the $35,624 visible price included it. At Dealer 500, $60,730 and $61,530 corresponded to MSRP and a price including an $800 processing fee. These were not counted as confirmed price errors. Price review
Other price differences remained unresolved after fresh captures because the offer basis or qualifications could not be established confidently. They remain unresolved in our analysis. Matching an amount does not prove that fees, eligibility and transaction terms are universally consistent.
What this means: Someone checking a budget needs to know what they would be comparing. A price that includes a required fee and a price that excludes it are different amounts for an explainable reason. A rebate available only to some buyers is not a price every buyer qualifies for. Accurate amounts need accurate labels and terms too, so software does not present an offer more broadly than the dealership intends. Establish that context before treating a difference as an error.
The code must be readable before its facts can be used
Direct inspection confirmed errors in JSON-LD, one format used to write schema, on four websites. These affected eight selected pages and 11 occurrences across the before-and-after captures. Readable records elsewhere on those pages still counted as present. We also found a separate homepage declaration written as //schema.org/AutoDealer, where the standard requires a full address identifying the type of record. Technical audit, WHATWG Microdata standard
These are findings from defined technical checks, not a complete validity certification. Multiple blocks, multiple offers, optional-property omissions and unfetched external references were not automatically classified as errors.
Why this matters: A badly formed block of code can prevent software from reading the facts inside it, even when the shopper's page looks normal. But readable code can still contain a wrong price or mileage. A useful check therefore has two parts: can the software read the record, and does the record tell the truth about the listing? Passing the first check does not establish the second.
How this extends earlier research
Savvy Dealer's January study brought attention to dealership websites and reported a proprietary readiness score across 100 sites. Its published page does not supply the complete site/page evidence, field rubric and content-verification log needed to reproduce those results independently. Our contribution is a different measurement design: five selected pages per website, paired HTML and DOM, explicit field semantics, visible-content checks, and a saved evidence trail. We did not reproduce or reuse its score. Savvy Dealer study
Other dealership studies use different access tests, samples, page choices or AI-citation outcomes. Their percentages should not be directly compared with our selected-VDP adoption rate. Research on semantic-markup veracity also supports separating declared types from the content they describe. Research review, Alrashed and colleagues
Google's retirement of its dedicated Vehicle Listing search feature in 2025 did not remove Car or Vehicle from Schema.org. Google also says no special schema is needed for its AI features. Neither schema adoption nor its absence, by itself, establishes AI understanding, citations, rankings, traffic or lost sales. This study measured none of those outcomes. Google's retirement announcement, Google AI-feature documentation, Schema.org Car
What this means: A dealer needs to know what a check actually established. “The page opened,” “the mileage field exists,” and “the mileage agrees with the listing” answer different questions. A useful report shows which one it tested and the evidence behind the answer. None of those checks alone tells you whether an AI service will recommend the dealership.
What can you do?
Give these prompts to an agent that can read page source and use a browser. Replace the bracketed address with your website. An agent without those tools should identify what it could not check. These prompts produce an inspection and a proposed fix list for your review; they do not authorize website changes.
1. Find out what your site tells software.
Check [website URL]. Inspect the homepage, one new-inventory results page, one used-inventory results page, and three new plus three used vehicle pages if available. Read the initial HTML and the page after JavaScript runs. Tell me which business and vehicle facts are in the structured data, which appear only after JavaScript, and which you could not verify. For each useful field, explain the shopper question it helps answer. Separate a field being filled in from its value being correct. Compare each vehicle's VIN, year, make, model, trim, price, currency, availability, image and seller with the visible listing. Show the exact URLs, check time and evidence. Do not submit forms or change the site.
2. Check mileage separately for new and used vehicles.
Check the sampled vehicle pages on [website URL]. For the primary VIN on each page, compare its listed condition, visible mileage, structured-data mileage and unit. Report new and used results separately. Distinguish missing markup, missing visible information, conflicting readings and unknown results. Never assume a new vehicle has zero miles. Reopen apparent conflicts before calling them errors. Show me a table with the page URL and the two values.
3. Check prices and inventory links.
On [website URL], compare each sampled vehicle's structured price with the price shown to shoppers. Identify MSRP, selling price, required fees, conditional rebates, finance payments and lease payments before comparing amounts. Leave an unclear price basis unresolved. On each sampled results page, match the displayed vehicles to the structured inventory by VIN or detail-page link. Keep pagination and sold cards separate. Show confirmed problems separately from items that need review.
4. Turn verified findings into a request your provider can use.
Using the findings above, prepare a short fix list for my website provider. For each item, include the exact URL and VIN if relevant, the observed problem, the evidence, why it matters, the proposed change and how we will check the result. Prioritize conflicting vehicle facts and unreadable markup, then useful missing fields and rendering dependencies. Draft the request for my review; do not send it or make changes. Do not promise ranking, traffic or AI-citation gains.
Why this matters: The outcome is a specific, checkable request—what to investigate, where the evidence is, and how to confirm a fix. That gives your team and provider a practical next step without relying on an unexplained score.
Study limits and disclosure. The sample favors accessible websites found in public group and association listings and is not nationally representative. Three VDPs share each website, with additional group and provider dependencies, so we do not report national confidence intervals. Direct AI-assisted review covered 132 pages from 44 websites, 95 selected field records and 70 rendering-category checks on 41 final pages, plus targeted technical, absence and dynamic checks. Independent recounts used separate code paths; this was not independent human adjudication or manual certification of every field. Automatic agreement labels remain candidates. DealerClaw is the study's publisher and offers managed AI-agent services to automotive businesses. Published September 8, 2026.
The supporting methodology, field definitions, verification notes and summary data are available below. Dealership and website-provider names are withheld. Original page records, source URLs, VINs and captures remain private. Public summary tables support checking reported counts and percentages; independent raw-page verification requires the private evidence archive.