Schema Markup·4 min read

Contact Page Structured Data: ContactPage Guide

Your SaaS support page already lists a phone number, a support email, and the hours someone answers. Contact page structured data restates those facts in a format machines can trust: an explicit ContactPage type wrapping an Organization and its ContactPoint. Done well, it feeds the contact details search engines display for brand queries and pushes back against scraped, outdated numbers floating around the web. Here's how the markup fits together, a worked example for a fictional support page, and the traps that make validators and users complain.

Open the tool All insights

Where contact page structured data earns its keep

Take Relaymail, a fictional email API company. Its customers are developers mid-incident who search "relaymail support" and want a human fast. Search engines assemble a brand panel for queries like that, and structured contact data is one of the sources they trust when deciding which phone number and email to show. Unstructured contact info gets scraped too, but scraping picks up stale numbers from old press releases just as happily.

ContactPage, like its sibling types, descends from WebPage. The interesting part is the second layer: a publisher Organization that carries a contactPoint array. That two layer shape means one script declares both the page and the support channels of the company behind it, which is exactly the pairing a brand query needs.

A worked ContactPage and ContactPoint example

A SaaS support page, start to finish.

Relaymail's page sits at https://relaymail.io/contact with the title "Contact Relaymail Support". With the organization details and a support line filled in, the generator's Recommended mode produces: {"@type":"ContactPage","name":"Contact Relaymail Support","url":"https://relaymail.io/contact","publisher":{"@type":"Organization","name":"Relaymail","url":"https://relaymail.io","contactPoint":[{"@type":"ContactPoint","contactType":"Customer Support","telephone":"+1-415-555-0114","email":"help@relaymail.io","availableLanguage":"English"}]}}.

Notice contactPoint is an array even with a single entry. That's intentional: companies routinely add a second channel later, sales alongside support, and the array shape means the structure doesn't change when they do.

ContactPoint fields explained, one at a time

The contactType value is free text, but conventional labels like Customer Support, Sales, or Billing are what consuming systems recognize, which is why the tool offers those six in a dropdown rather than a blank box. The telephone field wants an international format with country code, +1-415-555-0114, not (415) 555-0114, because a bare national number is ambiguous to a global crawler.

The email should be a monitored inbox, not a formality. And availableLanguage tells multilingual searchers which channel can actually help them; a single value like English is fine, and you can hand-edit the copied JSON into an array if your team answers in several languages.

Contact schema and local SEO: what ContactPage won't do

It's tempting to read contact schema and local seo as the same project, but they're neighbors, not twins. ContactPage carries no address, no geo coordinates, and no opening hours, so it does nothing for map pack rankings by itself. A dentist or restaurant needs LocalBusiness markup with all three; that's the type local algorithms actually consume.

Where ContactPage does contribute locally is consistency. The phone number in your schema, on your page, and in your business profiles should be character for character identical, because citation consistency is a signal local systems score. A SaaS company with no storefront, like our Relaymail example, loses nothing by skipping LocalBusiness entirely.

ContactPage mistakes that undermine the markup

The recurring failures are less about syntax and more about honesty:

A national-format phone number without a country code, which parses fine and geolocates wrong.
Listing an unmonitored marketing inbox as the support email, so the markup routes frustrated users into a void.
Running Recommended mode on a site that already publishes Organization JSON-LD, creating two competing entity declarations; Strict mode exists for exactly this case.
Pasting the ContactPage block into a global header so every URL on the site claims to be the contact page.
Letting the schema drift after a support change, like a retired phone line that lives on in the JSON for a year.

Getting more out of the ContactPage generator

Use the auto-fill pass as a mini audit. The tool captures your phone and email from tel: and mailto: links, so if it comes back empty, your contact details exist only as plain text, invisible to the same crawlers you're trying to inform. Adding proper links helps users on phones anyway.

Second tip: regenerate on change, not on schedule. The block is static, so bind updating it to your process for changing support channels. A third small one: keep the page title in the schema identical to the title tag, since mismatches there are an easy trust leak.

ContactPage next to the other entity tools

Three related builders on this site cover the neighboring jobs. The Organization Schema Generator creates the full company entity, logo, social profiles, and multiple contact points included, which is the block your ContactPage's publisher should agree with. The LocalBusiness Schema tool is the right choice when there's a physical location, since it adds address, geo, and opening hours.

And for the page that tells your story rather than answering tickets, the About Page Schema tool applies the AboutPage type with the same publisher-linking pattern you've seen here.