Schema Markup for Roofing Websites: What to Add and What to Skip

Structured data tells a search engine what a page is about in a form it does not have to guess at, and Google is clear that it does this to aid understanding and enable rich result features rather than to raise rankings. For a roofing website that means a short, honest set of types on the right pages, and a firm habit of never describing something the page does not actually show.

What structured data is for

Google’s introduction to structured data describes it as a standardised format for providing information about a page and classifying its content. The output, where a page qualifies, is a rich result: the extra detail that appears with a listing rather than a plain title and snippet.

The important framing is that markup does not make a page better. It makes a page legible. A page that says nothing useful, marked up perfectly, is still a page that says nothing useful. What markup does is remove ambiguity, so that a search engine reading an article about roof insurance claims can tell it is an article, who wrote it, when it was published, and what questions it answers, rather than inferring all of that from the HTML.

The types a roofing website should carry

The list is shorter than most schema guides imply, and the shortness is deliberate. Every type you add is something that has to stay true.

Organization or RoofingContractor, once

The business itself should be described once, on the home page. For an actual roofing contractor, Schema.org publishes RoofingContractor as a specific subtype of LocalBusiness, and using the specific type is better than the generic one because it is more precise.

Google’s local business structured data documentation covers the supported properties: name, address where you have a public one, telephone, opening hours, area served, and the link to your other profiles. A service area business that does not receive customers at its address should describe the areas it serves rather than inventing a storefront, and the markup should agree with what the Business Profile says.

One caution that applies to a whole category of trade sites: if the business is not a roofing contractor, it must not claim to be one. A marketing company, a directory or a lead broker describing itself with RoofingContractor markup is making a false statement about what the entity is, and both the policy risk and the honesty problem are obvious.

WebSite, once

A single WebSite entity on the home page names the site and can declare its internal search. It is small, it is stable, and it does not need repeating on every page.

Service, on the pages describing a service

A page about roof replacement should carry Service markup naming the service, the provider, and the area served. This is the type that most directly matches what a roofing service page is, and it is frequently missing in favor of piling more LocalBusiness markup onto every page, which is both redundant and imprecise.

BreadcrumbList, on anything nested

Any page below the top level should describe its position: home, then section, then page. This is cheap, it is nearly always eligible to appear, and it makes the result more readable by replacing a raw URL with a path.

Article or BlogPosting, on articles

An article should say it is an article, name its author, and carry its publication and modification dates. The author should correspond to a real named person or a clearly described persona with a page of their own, and the dates should be honest. Backdating or silently bumping a modification date to look fresh is the kind of small dishonesty that is easy to detect and pointless to attempt.

FAQPage, only where questions are visible

FAQ markup belongs on a page where the questions and answers are actually rendered, in the same words. Google’s FAQ documentation sets out the requirements, and it narrowed the visible rich result to a limited set of sites, so most roofing websites should expect the markup to describe the page correctly and produce no visible snippet.

That is still a reason to include it and not a reason to include it everywhere. A page with three genuine questions on it can carry FAQ markup. A page with no visible questions cannot, regardless of how tempting the feature once was.

The rule that prevents nearly every problem

Google’s structured data general guidelines state the requirement plainly: markup must represent the main content of the page, and the content described must be visible to users. Almost every structured data failure is a violation of that one rule.

The versions of it that show up on trade websites:

• FAQ markup for questions that exist only in the markup.
• Review markup for reviews nobody can read on the page.
• Aggregate ratings assembled from nothing in particular.
• Service markup for services the page does not mention.
• Opening hours in the markup that disagree with the hours printed in the footer.
• Prices in markup that do not appear anywhere on the page.

Each of those is a mismatch between what the page says to a person and what it says to a machine, and that is the definition Google uses for spammy structured data. The consequence is a manual action against structured data, which removes the site’s eligibility for rich results and takes work to lift.

Reviews: the one to be careful with

Review markup is where good intentions most often go wrong, and it is worth being specific because the temptation is strong for a trade business whose reputation is its product.

Google’s review snippet documentation sets out what is eligible and what is not, and two points matter most for a roofing company.

First, the reviews have to be genuine, they have to be about the item being marked up, and they have to be visible on the page carrying the markup. Pulling a star rating from a third-party platform and marking it up on your own site, where the reviews themselves are not shown, is not eligible.

Second, self-serving review markup, meaning reviews about the business as a whole placed on that business’s own site, is not eligible for the review snippet feature. This catches most roofing sites’ instinct, which is to put an aggregate rating on the home page.

The honest approach, and the one this site’s own pages take, is to present quotes as illustrative when they are illustrative, say so in visible text, and carry no rating markup at all. An invented five-star aggregate is a fabricated claim before it is a technical problem.

How to implement it, and where it should live

Google supports several formats and recommends JSON-LD, which is a block of structured data in the head of the document rather than attributes woven through the HTML. That separation is the practical argument for it: the markup can be generated from the same data the page is built from, instead of being maintained by hand alongside it.

That last point is the one that decides whether structured data stays correct a year later. Markup pasted into a page by a person will drift, because somebody will change a price, a service or an address on the page and not in the block. Markup generated from the page’s own content cannot drift, because there is only one source. On a site where each page type emits its own schema automatically, adding a new service page produces correct Service and BreadcrumbList markup without anybody remembering, and that is the difference between structured data that works and structured data that quietly became false.

Validate it, then validate it again after changes

Use the Rich Results Test to confirm a page is eligible for the features it should be, and watch Search Console for structured data errors over time. The second half matters more than the first: markup is usually correct on the day it is written and broken three deploys later, and the report is the only thing that will tell you.

Connecting the entities so they describe one business

A common state on a roofing website is markup that is individually valid and collectively incoherent: an Organization on the home page, a Service on a service page, an Article on a post, and nothing saying they belong to the same business. Each block is an island.

The fix is to give the business a stable identifier and to refer back to it. In practice that means the organization gets one canonical identifier, usually a URL fragment on the home page, and every other block that needs to name the provider, the publisher or the author points at that identifier rather than repeating a copy of the whole organization inline.

The benefit is twofold. A search engine gets a graph describing one business with several pages rather than a set of unrelated claims, which is closer to the truth. And, more practically, the address exists in exactly one place, so changing it changes it everywhere instead of leaving stale copies on thirty service pages.

The same discipline applies to the connection outward. The organization block should list the profiles the business genuinely controls: the Business Profile, the social accounts you actually post to, the industry directory listings that are really yours. Those links are how the entity on your site gets associated with the entity elsewhere. Listing a profile you abandoned in 2019, or one that belongs to a different company with a similar name, works against that.

What changes when you add a page

Most of the value of getting this right shows up not on the day of the audit but six months later, when the site has twenty new pages on it.

If schema is generated per page type, a new town page arrives with a correct Service block, correct breadcrumbs and a correct pointer to the organization, without anybody thinking about it. A new article arrives with the right author, the right dates and, if it carries visible questions, the right FAQ block matching them word for word.

If schema is pasted, a new page arrives with whatever the person who made it copied from the last one, which means last month’s service name, possibly last year’s phone number, and a set of FAQ entries describing questions that are not on the page. That is not a hypothetical failure mode; it is the single most common way a site acquires a structured data manual action, and it happens gradually enough that nobody connects the cause to the effect.

This is the real argument for treating structured data as part of how the site is built rather than as a task somebody performs on the site. It is not that hand-written markup is wrong on the day it is written. It is that it has no mechanism for staying right.

What to skip

HowTo markup for roofing work. Aside from the feature having been retired, a website that is not a licensed contractor publishing step-by-step instructions for roof work is a liability question before it is an SEO question.

Product markup for a service. A roof replacement is not a product with a SKU. Product markup on a service page is a mismatch, and it can trigger merchant listing errors in Search Console that take time to understand and undo.

VideoObject for a video that is not there. Only mark up a video that is actually embedded and playable on the page.

Speakable, JobPosting, Event and the rest of the catalogue, unless the page genuinely is that thing. The instinct to add every available type is the instinct that produces manual actions.

Duplicating the business on every page. One description of the organization, on the home page, is enough. Repeating full LocalBusiness markup on forty service pages does not multiply anything; it just creates forty places for the address to become wrong.

Structured data and AI answers

A question that comes up constantly now: does marking a page up help it get used in an AI-generated answer. The honest response is that nobody outside the companies building those systems knows precisely, and anybody claiming a specific mechanism is guessing.

What can be said with more confidence is directional. A page that states clearly what it is, who wrote it, what business stands behind it, and what question each section answers is easier for any system to interpret, whether that system is a crawler building an index or a model assembling an answer. Structured data is one of several ways a page does that, alongside plain things like a sensible heading structure, an answer in the first sentence under each heading, and facts attributed to a named source.

What is definitely not true is that adding markup to a thin page makes it a candidate for anything. The page still has to say something worth quoting, and for a roofing company that generally means local specifics and operational detail that only somebody who does the work would know. Markup makes that legible. It does not manufacture it.

The practical implication is a boring one: do the markup properly because it is cheap and correct, keep it matched to the page, and put the remaining effort into the content itself rather than into chasing whatever schema type is rumoured this quarter to influence an answer engine.

A short audit you can run

Pick four pages: the home page, a service page, a town page and an article.

• View the source and find the JSON-LD block. If there is not one, that is the finding.
• Read what it claims and compare it line by line against what is rendered on the page. Every claim visible.
• Check that the business name, phone number and address match the Business Profile exactly.
• Check the article’s author and dates are real.
• Run each page through the Rich Results Test and note what it says is eligible.
• Open Search Console and look at the structured data reports for errors accumulated since the last change.

If all four pages come back clean and consistent, the markup is doing its job, and the next improvement to the site is almost certainly not more schema. That is the useful conclusion to reach, because structured data is one of the areas where it is easiest to spend a month on work that was already finished.