Schema markup is machine-readable information that describes what a webpage is about. On a contractor website, it can identify the business, connect a service to its provider, describe an article, and explain a page's place in the site hierarchy. It does not create facts, replace visible content, or guarantee a rich result or a higher ranking.

The practical rule is simple: mark up the real entity or content that the page visibly describes, using the most specific supported type you can maintain accurately. A smaller, truthful graph is more useful than a large block filled with guessed service areas, borrowed reviews, or properties added only because a generator offered them.

This guide helps contractors and home-service businesses decide what to mark up, where it belongs, and how to test it. It complements the broader contractor website design checklist and the technical foundation described in SEO-first website development.

Understand the three layers before choosing a type

Schema work becomes confusing when three different concepts are treated as interchangeable:

  1. Schema.org vocabulary defines types and properties such as Organization, LocalBusiness, Service, areaServed, and provider.
  2. A data format carries that vocabulary in the page. Google supports JSON-LD, Microdata, and RDFa and generally recommends JSON-LD when the site can maintain it.
  3. A search feature is a presentation that a search engine may choose to show for a supported type. Eligibility is not a promise that the feature will appear.

A Schema.org property can be valid without powering a special Google result. Conversely, a type listed in Google's search gallery has feature-specific requirements beyond producing valid JSON. Use Schema.org to describe the entity, then use the current search-engine documentation to understand eligibility and required properties.

For most contractor sites, JSON-LD is the maintainable choice because the structured object can be generated from the same approved business data used by the visible page. The format is not a shortcut around accuracy. The text, links, images, hours, services, and locations represented in the markup still need to agree with what a visitor can verify.

Start with an entity and page inventory

Do not begin by pasting every available type into the homepage. First list the things the website can support with approved facts.

| Website item | Likely schema type | Typical owner | | --- | --- | --- | | The company or legal operating entity | Organization or an appropriate subtype | Homepage or about page | | A customer-facing physical location | A specific LocalBusiness subtype when eligible | Location or contact page | | A service the contractor actually provides | Service | The corresponding service page | | Navigation hierarchy | BreadcrumbList | Each eligible deeper page | | An original resource | Article or BlogPosting | The article page | | A genuine project example | Often CreativeWork or a conservative page-specific type | The case-study page |

This is a planning table, not a rule that every row must be implemented. The page must first have a clear purpose and complete visible information. Structured data should describe that page, not compensate for a thin service page or an incomplete location policy.

Record where each fact comes from and who owns updates. Useful fields include the public business name, canonical URL, approved logo, public telephone, business model, customer-facing address if applicable, actual services, service areas, opening hours, and public profiles that unambiguously identify the same entity.

If a field is disputed or awaiting approval, omit it. "Unknown" is not a reason to guess.

Choose Organization or LocalBusiness deliberately

Organization describes an organization. Google recommends placing organization information on the homepage or a single page about the organization rather than repeating the full object on every URL. Use properties that help a reader identify the same real business, such as its name, URL, logo, telephone, address where applicable, and verified public profiles.

LocalBusiness is both an organization and a place. Google's local-business documentation requires a physical address for eligibility for its local-business feature. That makes the decision especially important for contractors that travel to customers and do not receive customers at a staffed public location.

Use this decision sequence:

  • Customers visit a real, staffed location during the stated hours: evaluate the most specific valid LocalBusiness subtype and publish the actual address.
  • The company has multiple customer-facing locations: model each real location separately rather than combining several branches into one invented place.
  • The company travels to customers and hides its address in its Business Profile: do not insert a virtual office, mailbox, employee home, or unstaffed address merely to satisfy a property.
  • The site cannot substantiate a public place: use an accurate organization model and describe real services and coverage in visible content. Do not imply that an Organization object is a storefront.

The structured data and Google Business Profile information should remain consistent, but they are different systems. Adding a service area to a website does not change a Business Profile, create local eligibility, or prove that the contractor operates from a location.

Describe services without manufacturing locations

Schema.org defines Service for a service provided by an organization. Useful properties can include the service name or type, provider, and the real area served. A contractor service page is a sensible owner when the visible page already explains:

  • what the service is;
  • who provides it;
  • the type of customer or property it fits;
  • material inclusions or limitations;
  • how an assessment or estimate begins;
  • the geographic coverage the business can fulfil; and
  • the next step.

Avoid using Service markup to turn a generic paragraph into dozens of supposed offers. If the site has one roofing service page, adding a separate service object for every city does not create a distinct local service. If operating coverage is broad or changes frequently, a conservative text value or a maintained administrative-area reference is safer than a brittle list of municipalities.

The same rule applies to price and availability. Do not publish an Offer, price, emergency availability, or round-the-clock hours unless the visible page and operating process support the claim. A schema generator cannot approve commercial terms.

Match markup to the page's main content

Google's structured-data guidelines require markup to represent the page's main visible content. That leads to a useful page-by-page pattern.

Homepage or about page

Establish the organization identity once. Give the entity a stable @id, commonly a canonical URL with a fragment, so other page objects can refer to the same organization without recreating conflicting versions.

Service page

Describe the visible service and connect its provider to the established organization. Do not mark every page as every service the company performs.

Resource article

Use Article or BlogPosting with an accurate headline, dates, image, author, and publisher. Google recommends that the authors visible on the page also appear in the markup. Updating dateModified should reflect a meaningful reviewed change, not an automated daily timestamp.

Deeper site pages

Use BreadcrumbList when a visible hierarchy helps the visitor understand where the page sits. Google says the trail should represent a typical user path; it does not have to mirror each URL segment.

Contact or location page

Place public contact and location facts where visitors can verify them. A map embed or city name alone does not prove that a business operates a customer-facing branch.

This ownership model reduces contradictions. A phone-number change can update one approved entity record instead of requiring manual edits across hundreds of copied JSON blocks.

Treat reviews and ratings as a high-risk area

Review markup is where otherwise careful contractor websites often overreach.

Google's review-snippet guidelines say that pages controlled by a local business or organization are ineligible for the star review feature when the reviewed entity is that same business. The restriction still applies when the site embeds reviews from another platform. Google also says not to aggregate ratings from other websites and requires marked-up review content to be visible to users.

That means a contractor should not:

  • copy a Google rating into aggregateRating on its own LocalBusiness object;
  • calculate a combined score from Google, Facebook, and another directory;
  • add invisible testimonials only to the JSON-LD;
  • change a customer's wording, author, date, or score;
  • create a rating from internal staff judgement; or
  • assume a review widget makes self-serving stars eligible.

Genuine testimonials may still help a visitor when the contractor has permission to publish them accurately. That is a content and evidence decision. It does not automatically create eligibility for a review rich result.

Build one maintainable graph

The goal is not to maximize the number of schema blocks. It is to keep the relationships clear.

A maintainable contractor-site graph commonly has:

  • one stable organization identity;
  • a website identity linked to the publisher;
  • a page-specific object that describes the current page;
  • a breadcrumb object on deeper pages; and
  • references between objects through stable @id values.

For a service page, the page-specific object can refer to the organization as its provider. For an article, the article can refer to the publisher. This avoids creating several organization objects with different names, telephone numbers, logos, or addresses on the same page.

Generate recurring values from one approved data source. Escape user-controlled text safely before serializing JSON. Produce valid JSON rather than a JavaScript object literal, and do not interpolate untrusted text into a raw script string. If a content management system or plugin generates markup, inspect the rendered HTML instead of assuming its settings screen matches the public result.

Nexxen's own resource system follows this page-specific pattern: an approved MDX resource supplies its headline, description, dates, author, reviewer, image, service relationship, and sources; the article route generates BlogPosting markup, while the shared breadcrumb component generates BreadcrumbList. Publication tests inspect the rendered output. This keeps editorial facts in the article record and reusable rendering logic in the website application.

Validate syntax, meaning, and delivery

Passing one validator is not the end of the work. Use three separate gates.

1. Syntax and feature validation

Run Google's Rich Results Test on representative rendered pages. Fix critical errors and review warnings against the current feature documentation. A passing result confirms that the tool can parse the supported markup; it does not confirm every statement is true.

For types and properties that Google does not treat as a rich-result feature, use a Schema.org-aware validator as a vocabulary check.

2. Visible-content and source validation

Compare each important property with the public page and the approved source of truth:

  • Does the business name match?
  • Is the canonical URL correct?
  • Is the telephone public and current?
  • Is the address a real eligible location?
  • Are hours accurate, including special hours?
  • Are service and area claims visible?
  • Are the author, dates, and image accurate?
  • Are reviews reproduced with permission and without unsupported aggregation?

Validation software cannot answer these questions.

3. Production delivery validation

Inspect the live canonical URL, not only a local preview. Confirm that:

  • the server returns a successful response;
  • the canonical page is indexable;
  • the JSON-LD appears in the rendered HTML;
  • there are no duplicate or contradictory objects;
  • scripts, consent tools, or client-side errors do not remove the markup;
  • the page is present in the intended navigation and sitemap; and
  • Search Console can inspect the production URL.

Re-test after template, CMS, plugin, contact-data, service-area, and review-widget changes. Structured data can become inaccurate without producing a code error.

Use a release checklist

Before publishing or changing contractor schema markup, record:

  • [ ] The page's primary entity or content type.
  • [ ] The visible source for every public property.
  • [ ] The canonical URL and stable entity identifiers.
  • [ ] The appropriate Schema.org type and current Google feature guidance.
  • [ ] The reason for choosing Organization or LocalBusiness.
  • [ ] The actual provider and service-area relationship.
  • [ ] The author, publisher, image, and dates for editorial content.
  • [ ] The visible breadcrumb path.
  • [ ] The origin and permission for any review content.
  • [ ] Rich Results Test results on representative pages.
  • [ ] A rendered-HTML inspection on production.
  • [ ] An owner and trigger for future updates.

Keep a short decision note for omitted properties too. "No public customer-facing address" or "no eligible first-party rating markup" prevents a future plugin or redesign from silently reintroducing unsupported claims.

Know what schema markup cannot do

Schema markup cannot:

  • guarantee a rich result;
  • guarantee indexing or rankings;
  • establish a location where the business does not operate;
  • make thin city pages unique;
  • turn a service name into evidence of expertise;
  • repair inconsistent business information;
  • make self-serving review stars eligible;
  • replace helpful visible content; or
  • keep changing facts accurate without an owner.

It can give machines a consistent description of a well-built page. That is worthwhile when the underlying content, business data, and site architecture are already reliable.

If schema is part of a larger implementation, website development for Canadian contractors should connect the markup to the same approved content model used by pages, navigation, metadata, and lead flows. The best implementation is not the longest JSON-LD block. It is the smallest complete representation the business can defend and keep current.