Roofing Schema Markup in 2026: The Complete Guide for Roofing Contractors
A March 2026 audit of 50 independent contractor websites on r/localseo found that roughly 70% had no LocalBusiness schema at all. Not wrong schema. Not outdated schema. Nothing.
That's the landscape. Roofing is one of the most competitive niches in local SEO nationally, and most independent operators are handing one more advantage to franchise competitors and regional chains that have fully structured entity signals across every page, service, and location.
Schema markup is invisible to the business owner. You can't see it when you browse the site. Customers don't mention it. No dashboard turns red when it's missing. And so it quietly doesn't exist on most roofing websites — until someone starts asking why the phone stopped ringing.
This guide covers what roofing schema markup actually is, how to implement it correctly in 2026, and where the current top-ranking guides — every one of them — get it wrong.
What roofing schema markup actually does
Schema markup is structured data you add to your website's code. It uses a standardized vocabulary from schema.org to describe your business in a format that search systems can parse directly, without inferring meaning from your page text.
When you add RoofingContractor schema to your homepage, you're explicitly telling search systems: this entity is a roofing contractor, located at this address, operating during these hours, serving these areas, with these certifications. That's different from writing "We're a roofing contractor in Pittsburgh" somewhere on your About page. Copy has to be interpreted. Schema is declarative.
Google has stated clearly that structured data is not a direct ranking factor. Adding schema to your site does not move you up in search results. What it does — what Google confirms — is help search systems understand your content and your entity. That understanding is what powers eligibility for rich results, supports entity recognition in AI Overviews, and builds the kind of entity clarity that makes your business consistently recognizable across the web.
If you've been sold schema as a "ranking boost," you received marketing copy, not technical accuracy. Schema is a communication layer between your website and search systems. It describes what you are, not how good you are.
For more background on how structured data fits into the broader search picture, the article What Structured Data for SEO Actually Does covers the foundational mechanics without the hype.
RoofingContractor vs LocalBusiness
The most common mistake in roofing schema implementation is using the wrong type.
The full schema.org hierarchy for a roofing business looks like this:
Thing
└── Organization / Place
└── LocalBusiness
└── HomeAndConstructionBusiness
└── RoofingContractor
RoofingContractor is the most specific applicable type for a dedicated roofing company. It inherits every property from LocalBusiness, Organization, and Place — so nothing is lost by using it. What you gain is precision.
Google's official LocalBusiness documentation states: "Use the most specific LocalBusiness sub-type possible." For a roofing company, that's RoofingContractor. Not LocalBusiness. Not Contractor — which isn't a schema.org type at all. Not GeneralContractor, which is a peer type under HomeAndConstructionBusiness suited to multi-trade general contractors.
The problem in practice: most schema plugins default to LocalBusiness. Unless you go in and manually set the @type to RoofingContractor, you're leaving specificity on the table every day. This is a fixable error that most roofing sites never fix.
If your company does roofing plus gutters plus siding, you have options. Use RoofingContractor as the primary type, or use HomeAndConstructionBusiness as a broader parent. For clearly multi-trade businesses, passing an array is valid: "@type": ["RoofingContractor", "GeneralContractor"] — but verify each type exists in schema.org before combining. GutterContractor, for example, does not exist in the schema.org vocabulary, and inventing a type doesn't create one. For gutter work, keep RoofingContractor as the primary type and describe gutter services in Service blocks on the relevant service pages.
What a roofing contractor schema block contains
A RoofingContractor schema block is delivered as JSON-LD — a structured text file placed in a <script> tag in your page's <head>. It doesn't change what visitors see. It describes your business to machines.
The block has two layers. The first is structural: a @context that sets the vocabulary (always schema.org), a @type set to RoofingContractor, and a @id — a stable URL fragment that gives your business entity a consistent identifier across every page on your site and across the web. Think of @id as the permanent record number for your business in the structured data graph.
The second layer is descriptive — the properties that carry entity information. Google requires name and address at minimum. The recommended properties are where the real entity signal lives: telephone, url, geo for precise coordinates, openingHoursSpecification, areaServed listing every city and region you serve, sameAs connecting your entity to external profiles and directories, hasCertification for manufacturer credentials, and description. Each of those properties is something a search system can parse, cross-reference, and use to build a more complete picture of who you are and where you operate.
One formatting note on hours: schema.org accepts both openingHours (a text shorthand) and openingHoursSpecification (a structured object with explicit days, opening, and closing values). Use the structured openingHoursSpecification format — it's more precise and more reliably parsed — and don't mix the two formats in the same block.
The complete annotated template — every property explained, every placeholder labeled, with implementation notes — is in the Roofing Schema Pack.
Where roofing contractor structured data goes wrong
Getting the type right is step one. Most implementations also fail on several of the properties above.
Missing sameAs
sameAs is the most underused property in local business schema, and none of the current top-ranking guides on roofing schema mention it. It links your business entity to its representations across the web — your Google Business Profile, BBB listing, Angi profile, NRCA membership page, LinkedIn page, and relevant industry directories.
This is how search systems and AI tools build confidence that the entity described in your schema is the same entity referenced elsewhere on the web. Without sameAs, your schema describes a business in isolation. With it, your schema connects an entity to a web of verifiable external references that confirm its identity.
For the GBP entry in sameAs, use your Maps CID URL — the stable, long-form URL from your Google Business Profile, not the shortened share link. A CID URL looks like https://www.google.com/maps?cid=XXXXXXXXXXXXXXXXX — a permanent numeric identifier for your listing. You can locate yours by opening your GBP share link in a browser and inspecting the resolved URL, or with any free CID lookup tool.
Missing geo coordinates
The address field communicates your location through postal data. The geo property gives search systems precise coordinates. Both are worth including, especially for businesses competing in dense metro areas where precise location matters for map-adjacent features.
Missing @id
The @id property gives your business entity a stable, unique identifier that persists across pages on your site and across the web. Typically, this is a URL fragment like https://yourdomain.com/#organization. When your service pages reference your main entity in their schema, they use this @id to establish the connection.
Stale data
Schema is set-and-forget until something changes — and then it often doesn't get updated. Phone numbers change. Hours change. Certifications are added. A second location opens. The schema still reflects what it said two years ago. Stale schema doesn't cause penalties, but it creates inconsistency between what search systems read in your markup and what they read in your GBP. That inconsistency is noise in your entity signal.
FAQPage schema after Google's May 2026 changes
This section exists because every current guide on roofing schema markup gets this wrong — including every page currently ranking in the top five for this topic.
Google deprecated FAQPage rich results on May 7, 2026. The FAQ accordion feature no longer appears in Google Search for any site — roofing companies, government sites, health publishers, none of them.
The timeline:
| Date | What Changed |
|---|---|
| August 8, 2023 | Google downgraded FAQ rich results — limited to government and health sites only |
| May 7, 2026 | Full deprecation — FAQPage rich results removed from Google Search entirely |
| June 2026 | Search Console FAQ reporting removed |
| August 2026 | Search Console API support for FAQPage removed |
If a guide tells you to add FAQPage schema to your roofing pages to get the accordion-style FAQ display in Google results, that guide was written for 2023. The visual feature is gone. This is not a partial rollout or a test. It's a confirmed, completed deprecation.
What to do with FAQPage markup already on your site:
You don't need to remove it. Google confirmed that existing FAQPage markup will not harm a site. The rich result simply won't appear. If you're doing substantial maintenance on those pages anyway, cleaning it out is reasonable housekeeping. If not, don't prioritize it.
Other search engines — Bing among them — may still process FAQPage markup. For most roofing contractors, the practical reality is that the time formerly spent building out FAQ sections for Google's accordion is better directed at entity signals that still produce measurable outputs.
sameAs and entity clarity
The underlying concept worth understanding is this: Google and AI systems don't know that the "Pittsburgh Roofing Co." on your website is the same entity as the "Pittsburgh Roofing Co." on Google Business Profile, the BBB, and your Angi listing — unless you connect them.
sameAs is the connector. When Google's systems follow those links and confirm a consistent entity — same name, same address, same phone number, same visual identity — that consistency is a signal that the entity is well-established and verifiably identifiable.
For roofing contractors, the highest-value sameAs targets are:
- Google Business Profile (Maps CID URL)
- BBB profile (especially with accreditation)
- NRCA directory listing
- Angi or HomeAdvisor profile
- LinkedIn company page
Industry certifications add another layer. GAF Master Elite contractors have a directory page on gaf.com. CertainTeed ShingleMaster contractors have one on certainteed.com. Owens Corning Preferred Contractors appear in the OC Pro network. Those are linkable entity references that search systems can resolve — and none of the current roofing schema guides mention them.
The hasCertification property is where those signals go in your schema. It's an explicit, documented schema.org property that allows you to name the certification, the certifying body, and link to the issuing organization — turning what would otherwise be a line of copy on your About page into a machine-readable entity relationship. If you hold any of the major manufacturer credentials, this property belongs in your implementation.
Conceptually, the structure is simple: hasCertification takes a Certification object with three working parts — a name (the credential itself, like GAF Master Elite), an issuedBy organization (the manufacturer or body that grants it), and a url pointing to your listing in the issuer's public contractor directory. That third field is what makes the credential verifiable rather than merely claimed. The production-ready implementation, with every field annotated, is part of the Roofing Schema Pack.
If you want to understand how entity signals interact with AI-generated search features specifically, Does Schema Markup Matter for AI Search? covers that question without making promises the data doesn't support.
Schema for roofing service pages
Your homepage schema establishes the business entity. Your service pages can carry their own structured data that connects each service to that entity and expands your site's topical coverage at the structured data level.
The applicable type is Service. Each block names the service, connects it to the main business entity via a provider field that references the homepage @id, declares the areaServed cities, and specifies the serviceType. The provider connection is the key mechanic — it creates a machine-readable link between the service page and the parent entity established on your homepage, so every service page reinforces the same entity rather than floating independently.
This matters for roofing companies with multiple service lines: roof replacement, roof repair, storm damage restoration, emergency tarping, metal roofing, flat and commercial roofing. Each of those services, on its own page, can carry a Service schema block that connects it to the same parent entity. That's the structured data equivalent of building out your site's topical coverage at the machine-readable level.
A note on serviceType: it's a plain text property — there's no controlled vocabulary — so use the plain-English name a customer would recognize. For roofing service pages, that means values like "Roof Replacement", "Roof Repair", "Storm Damage Restoration", "Emergency Tarping", "Metal Roofing", and "Flat and Commercial Roofing" — one per page, matching the service the page actually describes.
None of the current top-ranking guides on roofing schema cover service page structured data. They stop at the homepage RoofingContractor block and consider the job done.
Multi-location roofing businesses
A roofing operation running multiple crews out of different cities has a multi-location schema challenge that a single homepage block can't fully address.
For businesses with multiple locations, there are two approaches. The first nests each location as a sub-entity inside the main organization's schema block using the department property — each with its own name, address, phone, and coordinates. The second gives each location its own dedicated page with a standalone RoofingContractor schema block and unique @id, which is cleaner for operations with separate GBP listings per location and the one most implementers should default to. Each standalone location block should also carry a parentOrganization property pointing back to the main entity's @id, so every location reinforces one master entity instead of fragmenting it.
Either way, the governing rule is consistency: every address, phone number, and business name in your schema must match what's in your Google Business Profile exactly. The name format, the suite number, the phone format — all of it. Inconsistency across schema, GBP, and major directories creates noise in the entity signal that none of those sources individually can resolve.
Common plugin conflicts
Schema plugins are useful. They're also one of the most common causes of broken roofing schema.
The problem: multiple sources outputting schema for the same page simultaneously. RankMath generates a LocalBusiness block. Your theme has hardcoded schema in its template files. A review widget drops its own structured data. Now you have two or three schema blocks on the same page with different data — different addresses, different phone numbers, different types. Google has to decide which one to trust, and the answer is often: none of them.
One widely shared example: a site owner on r/SEO in October 2025 described a drop from page one to page three after two sources began outputting conflicting address values, with rankings recovering within weeks of removing the duplicate. Treat that as illustrative rather than proof — forum anecdotes don't isolate variables. But the principle stands on its own: Google's structured data guidelines depend on unambiguous signals, and two blocks asserting different addresses for the same entity is the definition of ambiguity.
How to find conflicts: Run your URL through Google's Rich Results Test. In the detected items, look for multiple entries of the same type on the same page. Two LocalBusiness or RoofingContractor blocks is a conflict.
Resolution: Pick one source of truth — typically your schema plugin — and disable schema output from every other source. Theme schema settings are often in the customizer, in a child theme file, or in a settings panel buried under "Advanced." Review widget documentation should include instructions for disabling structured data output; if it doesn't, contact support.
One schema source per page. That's the rule.
How to validate roofing schema properly
Adding schema without validating it is the same as not adding it. You need to confirm that search systems are reading it correctly.
Step 0: Schema.org Validator (pre-flight)
Before testing for Google eligibility, run your markup through validator.schema.org. The two tools answer different questions: the Schema.org Validator checks spec compliance — is this valid JSON-LD against the schema.org vocabulary? — while the Rich Results Test checks Google eligibility — does this qualify for a rich result? A block can be spec-valid but Google-ineligible, and occasionally the reverse. Clear the vocabulary check first, so anything the Rich Results Test flags afterward is an eligibility question rather than a syntax problem.
Step 1: Google Rich Results Test
Go to search.google.com/test/rich-results. Enter your URL. The tool shows which schema types were detected on the page and flags errors and warnings. Look for RoofingContractor in the detected items. Check the properties. Verify that name, address, telephone, geo, areaServed, and sameAs are present and populated correctly.
Note: Google is removing Rich Results Test support for FAQPage in June 2026 as part of the deprecation. For all other types including LocalBusiness and RoofingContractor, the tool continues to function.
Step 2: URL Inspection Tool in Search Console
After your schema is live and Google has re-crawled the page, run the URL through the URL Inspection Tool in Google Search Console. This shows what Google's crawler last read on that page and whether structured data was detected. Use this to confirm the live version of your schema is what you intended — not a cached or incorrectly rendered version.
Step 3: Search Console Enhancements Report
The Enhancements section in Search Console surfaces structured data errors across your entire site. This is where you find problems that don't show up in manual testing — rendering failures where schema is injected by JavaScript that Googlebot can't execute, or validation errors introduced by a plugin update.
Run this validation workflow every time you update your schema, change your site's theme or template, or install or update a plugin that touches structured data output. Schema is not fire-and-forget.
Before you go live
The schema equivalent of a final walkthrough is three questions.
Does the Rich Results Test detect RoofingContractor — not LocalBusiness — with zero errors on your homepage? Does the URL Inspection Tool in Google Search Console confirm that Google's crawler read structured data on the live page, not just on a test version? Does the Enhancements report in Search Console show no ongoing schema errors across the site?
Those three tools cover whether your schema exists, whether it's valid, and whether it's being read correctly in production. If you want a full property-by-property implementation checklist for both the homepage entity block and individual service pages, that's included in the Roofing Schema Pack.
Roofing schema markup FAQ
Should a roofing company use RoofingContractor or LocalBusiness schema?
Use RoofingContractor. It's the most specific applicable schema.org type for a dedicated roofing business, it inherits every property from LocalBusiness, and Google's documentation recommends using the most specific sub-type available. Reserve broader types like HomeAndConstructionBusiness for genuinely multi-trade operations.
Is FAQPage schema still worth adding in 2026?
Google stopped showing FAQ rich results in Search on May 7, 2026, for all sites. FAQPage markup may still be valid structured data when it matches visible page content, and other systems may still parse it — but don't add it expecting the old accordion result or guaranteed AI visibility. If a page has a real FAQ section, the markup is harmless to keep; it's no longer worth building pages around.
Does schema markup make a roofing website rank higher?
No. Google states that structured data is not a direct ranking factor. What schema does is help search systems understand your business entity — which powers rich result eligibility and clearer entity recognition across search and AI features. Anyone selling schema as a ranking boost is selling marketing copy.
What does the sameAs property do for a roofing contractor?
It connects your schema entity to your verified profiles across the web — your Google Business Profile, BBB listing, NRCA directory page, Angi profile, LinkedIn page, and manufacturer certification directories. That web of consistent external references is how search systems confirm your business is one well-established entity.
How do I check whether my roofing schema is working?
Run the markup through validator.schema.org for vocabulary compliance, then run your live URL through Google's Rich Results Test, then confirm with the URL Inspection Tool and the Enhancements report in Google Search Console. Those checks cover whether your schema exists, whether it's valid, and whether it's being read correctly in production.
Final thoughts
Roofing schema markup is not complicated once you understand what you're looking at. The type hierarchy is documented. The properties are explicit. The validation tools are free.
What creates the mess is bad information — guides that still recommend FAQPage schema for a rich result that stopped existing in May 2026, plugin defaults that leave sites on LocalBusiness when RoofingContractor is the correct choice, and agencies that sold schema as a ranking lever without explaining what it actually does.
Schema is one signal in a larger picture. It won't override thin content, an unmanaged GBP, or a site with nine pages competing against a franchise with seventy-four. What it does is remove ambiguity — for search systems, and increasingly for AI tools — about who your business is, where it operates, and what it does. That clarity compounds over time as your entity becomes more consistently recognizable across the web.
If you want to know where your current implementation stands before touching anything, the Free E.V.I.L. Scan covers your homepage schema as part of a 20-minute structured data check, no commitment required.
If you want a complete production-ready package — JSON-LD templates, a schema decision guide, service-page markup, and a validation workflow built specifically for roofing websites — the Roofing Schema Pack covers all of it.
And if you want a full review of your existing implementation with documented findings, a gap analysis, and a correction plan, that's what the Schema Health Review delivers.
Start with what you have. Validate it. Fix what's wrong.