HVAC Schema Markup: The Types That Still Earn Results

Google's framing of what markup buys you is deliberately narrow: "Google uses structured data to understand the content on the page and show that content in a richer appearance in search results, which is called a rich result."

Two entries need naming precisely: they get sold hardest. Service markup is a legitimate schema.org type describing your offerings accurately — it is simply not in the feature gallery, so no rich result exists for it to earn. FAQPage is worse: the feature it targeted is gone.

The AI question sits underneath all of this, and Google answers it in writing: "Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add. However, it's a good idea to continue using it as part of your overall SEO strategy, as it helps with being eligible for rich results on Google Search." Read both halves. No schema type gets an HVAC company into AI Overviews or ChatGPT answers, and no reason exists to strip markup out either. Ship it for the rich results and the entity clarity, not as an AI product.

HVACBusiness is a real schema.org type, defined as "A business that provides Heating, Ventilation and Air Conditioning services", sitting in the hierarchy Thing > Organization > LocalBusiness > HomeAndConstructionBusiness > HVACBusiness. Schema.org's own usage panel puts the type on "10K - 100K Domains", a figure it captions "Based on monthly aggregations from Google's web index." and stamps "(Google - July 2026)" — established enough to be safe, specific enough to be a signal most contractor sites still skip.

Be precise about the return, because this is where proposals inflate. Google's gallery entry for the Local business feature promises one thing: "Business details displayed in the Google knowledge panel, including open hours, ratings, directions, and actions to book appointments or order items." Google frames even that as being "eligible to appear in Local Business rich results", not guaranteed one. Neither page attributes a map-pack position to on-page markup. Google puts that surface somewhere else entirely: its Business Profile help says "You can use your Business Profile to improve your business's local ranking", and that local results are "mainly based on relevance, distance, and popularity". Your JSON-LD is not on that list.

Use it rather than plain LocalBusiness; Google's instruction is explicit: "Use the most specific LocalBusiness sub-type possible". The required-property bar is also far lower than agencies imply — Google's LocalBusiness reference requires exactly two properties, address and name. Everything else is recommended: geo, openingHoursSpecification, priceRange, telephone, url, department.

A complete, honest block for a single-location shop. Paste this inside a <script type="application/ld+json"> tag in your page head — JSON-LD is Google's recommended format:

{
  "@context": "https://schema.org",
  "@type": "HVACBusiness",
  "name": "Smith Heating & Air",
  "url": "https://example.com/",
  "telephone": "+1-303-555-0142",
  "priceRange": "$$",
  "image": "https://example.com/img/shop-front.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1420 W Colfax Ave",
    "addressLocality": "Denver",
    "addressRegion": "CO",
    "postalCode": "80204",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 39.7402,
    "longitude": -105.0233
  },
  "areaServed": [
    { "@type": "City", "name": "Denver" },
    { "@type": "City", "name": "Lakewood" },
    { "@type": "City", "name": "Wheat Ridge" }
  ],
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "07:00",
    "closes": "18:00"
  }]
}

Five rules decide whether that block helps or quietly does nothing:

1. Every value must appear on the page. Google's guidelines say "Don't mark up content that is not visible to readers of the page". If the markup claims 7am–6pm and your footer says 8am–5pm, you have shipped a contradiction, not a signal.
2. Match your Google Business Profile exactly. Same legal name, same street address, same phone. Markup that disagrees with your profile gives Google two versions of one business to reconcile — and the profile is the copy that feeds the map pack, so the profile fields your markup has to agree with are the ones to settle first.
3. One block per business, not one per page. Repeat the same HVACBusiness block site-wide via your template, or place it once on the homepage. Twenty variants across twenty pages is twenty chances to drift out of sync.
4. Combine types as an array, never with additionalType. Google states: "If you have multiple types, specify them as an array (additionalType isn't supported)." A company that genuinely belongs to two schema.org types — an HVAC business that also runs a parts counter, say — writes "@type": ["HVACBusiness", "Store"], not two competing blocks.
5. Use areaServed for your service radius; do not invent addresses. A single shop that covers nine suburbs lists nine areaServed cities and one real address. Registering a virtual office per suburb to justify nine address blocks puts a real, staffed-location requirement on a listing you cannot staff — we do not do it, and no markup gain is worth gambling the profile.

Multi-location contractors use department to nest branches under one parent entity. Add BreadcrumbList alongside it — a breadcrumb trail "indicates the page's position in the site hierarchy" and needs only itemListElement, with item, name and position on each entry. Most contractor templates already hold that data.

Google's advice on stale markup comes from a named source. John Mueller, bylined on the post as "Search Advocate, Google Switzerland", wrote in the August 2023 announcement:

"While you can drop this structured data from your site, there's no need to proactively remove it. Structured data that's not being used does not cause problems for Search, but also has no visible effects in Google Search."

So the correct response to a site full of FAQPage blocks is not a cleanup project. It is a line-item review: a monthly charge for FAQ schema maintenance stopped buying anything on May 7, 2026, and the fix is a conversation, not a code change.

The same discipline applies to the newer wave of AI-flavoured markup claims. Google's AI-optimization guide states that "You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search (including its generative AI capabilities), as Google Search itself doesn't use them" — the same section that dismisses content "chunking" and inauthentic mentions. The file version of that promise gets the same treatment in our breakdown of what a root-level AI text file really does; the schema version fails for the identical reason. A self-declared description is a claim, and engines that can read your pages directly do not need your claim about them.

The stars an owner points at usually come from a different surface: the Google Business Profile that feeds "local results on Google Maps and Search", or a directory page about you, where the reviewed entity does not control the reviews. Markup on your own site cannot reproduce them.

Filling the gap with invented numbers runs into two further constraints.

Google's guidelines add a content rule on top of eligibility: "Don't include fake or undisclosed incentivized reviews on your page or in your structured data markup", covering both reviews not based on genuine experience and reviews written in exchange for a benefit without clear disclosure. Google logged that guidance addition in its July 2026 documentation updates.

The legal constraint is heavier. The FTC's final rule on consumer reviews, announced August 14, 2024 on a 5-0 Commission vote, addresses reviews and testimonials that misrepresent that they are by "someone who does not exist, such as AI-generated fake reviews, or who did not have actual experience with the business" — and, in the Commission's own words, will "allow the agency to seek civil penalties against knowing violators." The rule's other prohibited categories govern how reviews get collected rather than how they get marked up, so they sit with which review-collection tactics the rule puts off limits. What matters here is narrow: a hand-typed AggregateRating of 4.9 from 312 reviews that do not exist is not a schema error. It is a representation about your business, in machine-readable form, on a page you publish.

So the honest position on review markup for an HVAC site has three parts:

1. Do not place AggregateRating about your own company in your own markup. It is ineligible, and if the numbers are not real it is a legal exposure with your name on it.
2. Earn the stars where they render. Google's Business Profile help is direct about what moves them: "More reviews and positive ratings can help your business's local ranking." That is a review-collection workstream, described in how we run profile and reputation work month to month, not a markup task.
3. Where reviews about someone else are genuinely the page's subject — you reviewing a piece of equipment, for instance — Review requires author, itemReviewed and reviewRating.ratingValue, and the rating must be real.

The maintenance loop is short enough to run yourself:

1. Run the Rich Results Test on one page of each template — homepage, a service page, a blog post. Templates repeat, so three tests cover a whole site.
2. Paste the same block into the Schema Markup Validator to catch schema.org errors Google's tool ignores because no feature depends on them.
3. Check Search Console's rich result status reports after deployment. Google directs site owners there "to monitor the validity of your pages" — it reports what Google saw on the live site, which is the only report that matters.
4. Re-test after any change to hours, phone, address or template. Markup drifts silently; nothing on the page turns red when the JSON-LD still says the old number.
5. Read the Manual Actions report if a feature disappears. A structured-data manual action means a page "loses eligibility for appearance as a rich result; it doesn't affect how the page ranks in Google web search" — painful, but not the ranking catastrophe it gets described as.

Most broken markup on contractor sites fails one of two ways. The first is markup that no longer matches the page: a seasonal phone number, revised hours, a rebrand the template never propagated. Google's requirement is that structured data "must be a true representation of the page content", and stale is a form of untrue. The second is missing required properties — Google states that "Items that are missing required properties are not eligible for rich results", which for HVACBusiness means a block with no address earns nothing at all, however much else it contains.

Markup belongs in the site template, generated from one source of truth, so a phone-number change updates every page at once. Markup maintained by hand across pages will be wrong within a year — and unlike a broken layout, nobody notices.

Order the work accordingly: ship the markup because it is cheap and finished, not because it is powerful. Spend the remaining budget on the pages, the speed and the proof.