Structured Data for a Commercial Vehicle Hire Website

Structured data is a standard way of telling a search engine what a page is about in a form it can read without interpretation. For a commercial vehicle hire website that means four types carry almost all the value: an organization described once, a service described on each service page, a local business described on each depot page, and breadcrumbs on anything nested. Everything beyond that list is either not applicable or actively risky. This article covers what each type is for, where it belongs, the rules that keep markup honest, and how to tell whether any of it is working.

What structured data is for, precisely

The first sentence answers it: structured data exists so a search engine does not have to infer from prose what a page already knows about itself. Google’s introduction to structured data describes it as a standardised format for providing information about a page and classifying its content, and notes that for certain types it can make a page eligible for richer presentation in results.

Two words in that description carry the weight. Classifying is the everyday benefit and applies broadly: a depot page marked as a local business is unambiguous in a way that an address in a paragraph is not. Eligible is the narrower one: some types can unlock enhanced presentation, but eligibility is not a promise, and Google is explicit that it decides what to show.

What it is not for

It is not a ranking lever you can pull on a weak page. It is not a place to put claims the page does not make. And it is not a substitute for the information being present and readable, which remains the actual requirement for a human buyer.

The clearest way to think about it is as a machine-readable duplicate of a page that is already correct. If the page is wrong, the markup is wrong in a more structured way.

The four types that matter

Organization, once

The business itself is described once, on the home page, with a stable identifier that every other block can reference rather than repeat. Name, URL, logo, contact point, area served. The temptation to restate the organization on every page should be resisted: repeating it does not reinforce anything and it creates several places where the same fact can drift out of alignment.

Give the organization block a stable identifier and reference it by that identifier from the service and article blocks elsewhere on the site. That way the business is defined in one place and pointed at from many, which is both cleaner and much easier to keep true.

Service, on service pages

A page that describes something you do is a Service. Schema.org documents the type, and the properties that matter for a hire business are the service name, a description, the provider (a reference to the organization), the area served and the audience. A page about contract hire website design, or about multi-depot structure, is a service page and should say so in markup.

The common error is reaching for a commerce type instead. A page describing a service you provide is not a product listing, and marking it as one invites eligibility checks for presentation you cannot satisfy, which surfaces later as a pile of errors in Search Console about missing price and availability fields.

LocalBusiness, on depot pages

Depot pages are the strongest structured data opportunity on a fleet site because they describe a real physical location. Google documents local business structured data with properties for the address, the opening hours specification, the telephone number and the geographic coordinates.

Mark up the depot, not the parent company, on the depot page. The page is about that location; the markup should be too. And every property must correspond to something visible on the page, which in practice means the address, the hours and the phone number all appear as readable text.

BreadcrumbList, on anything nested

Breadcrumbs are the least glamorous and the most consistently worthwhile. Google documents breadcrumb structured data as a way to indicate a page’s position in the site hierarchy, and on a site with services, fleet types, depots and articles that hierarchy is real and useful.

The rule is that the breadcrumb trail in markup matches the trail a person can see and use. A breadcrumb block describing a path that does not exist in the navigation is markup describing a fiction.

Types to use carefully, and types to avoid

FAQPage

FAQ markup is legitimate on a page that genuinely presents questions and answers as its content. A frequently asked questions page qualifies. A pricing page with a real objections section qualifies. A vehicle class page with three questions bolted on so that markup could be added does not, and that pattern is precisely what the general guidelines warn against.

The other rule is that the marked-up text must match the visible text exactly. Summarising the answer in the markup and writing a longer one on the page means the two can drift, and a drifted answer is a misleading one.

Review and AggregateRating

This is where fleet sites most often go wrong. Marking up ratings that were not collected through a genuine process, or that are not visible on the page, is a straightforward guidelines violation. If your reviews are illustrative examples rather than verified customer feedback, they must be labelled as such on the page and they must not be marked up as reviews. The honest position costs nothing and the dishonest one risks a manual action.

Vehicle and Offer

There is a temptation, on a page about a vehicle class, to mark it up as a vehicle or an offer with a price. Think carefully before doing so. If the page presents an actual, purchasable, specific offer with a firm price, the markup may be appropriate. If it presents an indicative rate for a class of vehicles subject to availability and term, then a structured offer with a price is a claim the business cannot stand behind, and buyers who see that price presented as firm will arrive expecting it.

The rules that keep markup honest

Google’s general structured data guidelines are short and worth reading in full, but three rules account for nearly every problem in practice.

Represent the page. The markup describes the main content of the page it is on. Not the site, not a related page, not what you wish the page said.

Be visible. The information in the markup should be visible to a visitor. This is the rule that catches invented hours, hidden prices and phantom questions.

Do not mislead. Markup that overstates, that marks up content generated for the purpose, or that describes an entity the page is not about, is a violation regardless of whether it validates.

The maintenance rule that is not in the documentation

Add one of your own: markup is generated, never typed. Structured data written by hand into a template will be correct on the day it is written and wrong within two quarters, because the page changes and the markup does not. Generating the block from the same data the page renders from means the two cannot disagree, which removes the entire category of drift errors.

Where the markup should live

Use JSON-LD in a script block. Google lists it among the supported formats and it is the only one that keeps the markup in one readable place rather than threading attributes through the HTML.

One block per page type, injected by the layout that owns that page type, is the pattern that scales. The depot layout emits the local business block. The service layout emits the service block. The article layout emits the article block plus its author and breadcrumbs. Individual pages do not hand-write markup, which means an individual page cannot get it wrong.

Avoid duplication

Two blocks describing the same entity on one page is a common and avoidable error, usually caused by a plugin adding a block that the template was already producing. Audit what is actually in the rendered page rather than what you think you added.

Checking that it works

There are two distinct checks and they answer different questions.

While building, validate the markup with a structured data testing tool. This catches syntax errors, missing required properties and type mismatches. Do it on one page of each type, not on one page of the whole site, because the templates are what differ.

After publishing, watch the enhancement reports in Search Console. These are the only source that tells you whether the markup is being processed across every page rather than on the URL you happened to test. They are also where a template-level error surfaces as a few hundred identical warnings, which is exactly the signal you want.

What success looks like

Success is not a rich result. It is the absence of errors across the whole site, plus markup that still matches the page six months later. Enhanced presentation, where it appears, is a consequence of the page being good and the markup being correct, and it is entirely at the search engine’s discretion.

Be suspicious of any advice that treats a rich result as a target to be engineered. The engineering that reliably works is making the page genuinely answer the question, then describing it accurately.

A worked pass over a fleet site

It helps to walk a whole site once and say what each page type gets, because the decision is usually obvious once the question is asked directly.

The home page gets the organization block and a website block, plus a service block describing what the business does in general terms. This is the only page where the organization is defined. Everything else references it.

Service pages get a Service block naming that specific service, referencing the organization as provider, with the area served and the audience filled in. If the page carries a genuine questions section in visible text, it also gets an FAQ block whose text matches word for word.

Fleet type or audience pages get a Service block too, because a page describing what you build for construction fleets is a description of a service for a segment, not a separate entity type. Add breadcrumbs, because the page sits under a parent index.

Depot pages get the local business block for that depot and breadcrumbs. They do not get the organization block.

Vehicle class pages get a Service block or nothing at all, depending on whether the page describes something you provide or simply catalogues a category. Resist the urge to invent a type for them.

Articles get an article block with the headline, description, dates, author and publisher, plus breadcrumbs, plus an FAQ block if the article genuinely ends with questions and answers in visible text.

Legal pages get a plain web page block and nothing more. There is no benefit in describing a privacy policy in elaborate detail and no type that fits it better.

What to do with pages that fit nothing

Some pages genuinely do not map onto a specific type. A thank you page, a search page, a template gallery. The correct markup for those is a simple web page block, or none. Forcing a type onto a page that does not match it is worse than leaving it plain, because an incorrect classification is a misleading one and a missing classification is merely absent.

The three failures that cost the most

Three specific mistakes account for most of the damage done by structured data on sites in this category, and all three are avoidable.

The first is marking up ratings that are not real. It is the fastest route to a manual action and the hardest to explain afterwards, and it happens most often when illustrative testimonials written for a launch get treated as review data by a plugin that cannot tell the difference. If the quotes on the page are illustrative, the page says so and nothing is marked up as a review.

The second is marking up a price that is not a price. An indicative day rate on a vehicle class page becomes, through an offer block, a firm published figure. Buyers arrive expecting it, the desk cannot honour it, and the conversation starts from a correction.

The third is quiet decay. Markup written by hand eighteen months ago now lists a depot that has closed, hours that changed last winter and a phone number that reaches nobody. Nothing alerts anyone, because invalid markup produces errors while merely out-of-date markup validates perfectly. This is the one that generated markup solves completely and no amount of care solves permanently.

Answering machines as well as search engines

There is a second audience for this markup now, and it changes the emphasis slightly.

Systems that summarise and answer questions rather than returning a list of links have to decide what a page asserts. A page whose claims are structured, explicit and consistent with its visible text is straightforward to summarise correctly. A page whose key facts live only in a photograph of a price list, or in prose that hedges every statement, is not.

This does not call for a new type of markup or a different strategy. It raises the value of the same discipline: say the important things in text, structure them, and keep the structure true. A depot page that states its hours in readable text and repeats them in an hours specification is easy for any system to read correctly, human or otherwise.

The practical consequence

Two habits get more valuable. First, answer-first writing: the first sentence under a heading answers that heading, so any system extracting a short answer extracts the right one. Second, unambiguous naming: calling a vehicle class what your buyers call it, consistently, across every page and every markup block, rather than varying it for prose rhythm.

Neither of these is a search technique. They are both simply clearer writing, which is the reason they hold up as the systems reading the page change.

Structured data on a site that keeps changing

A fleet site is not static. Depots open, classes change, articles publish weekly. Markup that was correct at launch has to stay correct through all of that, and it only does if it was generated rather than authored.

That is the real argument for building structured data into the templates rather than adding it as a layer afterwards. When a depot’s hours change, one record changes and both the visible page and the markup follow. When a new service page is added, it arrives with its Service block already correct because the layout produced it.

If you are assessing an existing site, start by rendering three pages of different types and reading the markup that comes out. If it is missing, wrong, or describing something the page does not say, the fix is structural rather than cosmetic, and the fleet website redesign page sets out how that is approached without losing what is already working. For a site being built from the beginning, the features page covers what is emitted by default and the services index covers the page types it applies to.