Schema Markup for Service Websites: Organization, Article, FAQ, and Service

The short version #

Structured data is a machine-readable summary of your page for search crawlers and AI summarizers. It helps Google, Bing, ChatGPT, and Perplexity understand who you are and what each page is selling. It does not, by itself, push you up the rankings. A service-business website needs four things: Organization plus WebSite on the home and About pages, Article or BlogPosting on the blog, Service on every service page, and FAQPage only when there are real, visible Q&As on the page. The biggest mistakes we see are using FAQ markup as a keyword bucket, putting content in schema that doesn't appear on the page, and shipping an Organization block that contradicts what's on LinkedIn or in the website footer. On Vue/Nuxt, attach a JSON-LD block per page component. On WordPress, let Yoast or Rank Math handle the defaults and hand-write Service schema for service pages. The priority list at the bottom is the version we use during audits.

We recently took over a website for a Chinese mechanical-parts exporter. Their previous agency had installed an "SEO plugin" but only WebSite schema was firing. The About page didn't even carry an Organization block, and the service pages were bare. Search Console showed no rich-result eligibility at all, despite a year of paid Google Ads spend. This is the typical pattern — a team assumes the SEO plugin took care of structured data, when in reality the plugin solved maybe 30% of it and the rest needs page-type-specific work.

This piece is for service businesses (B2B exporters, IT services, consultancies, custom manufacturing). It skips the "what is schema.org" encyclopedia and goes straight to: which page types need which markup, which fields Google actually uses for rich results, how to maintain it on Vue and WordPress, and how to QA it before pushing live.

Limits #

Schema helps Google, Bing, ChatGPT, and Perplexity parse your pages faster. It makes you eligible for rich results in the SERP — review stars, FAQ accordions, breadcrumbs, organization logo. And it strengthens entity signals, so search engines can confirm that "Mansion Tech, the company" maps to this site, this LinkedIn page, this address.

What it doesn't do is replace ranking factors. Content quality, links, and E-E-A-T move rankings. A badly written service page stays badly written, schema or no schema. AI Overviews still decide what to cite based on how clearly you answer the question and whether your numbers can be checked.

Google's own structured data documentation puts it bluntly: structured data makes your content eligible for rich results. Eligible is not the same as guaranteed.

Organization #

Every business website should ship Organization schema on the home page and the About page. It's the most important entity-card signal a search engine collects, and it's how AI search verifies you're a real company.

Required fields, at minimum:

• name: your registered English company name.
• url: the canonical site root.
• logo: an absolute URL to a square PNG or SVG, at least 112×112.
• sameAs: links to your verified profiles on LinkedIn, X, YouTube, GitHub, Crunchbase. This is the cross-validation signal, and the more complete it is, the better.

High-value optional fields:

• address (PostalAddress): a real office address. Buyers do look at this.
• contactPoint: an email or phone number with contactType set to customer support or sales.
• foundingDate, numberOfEmployees: gives AI summaries the metadata they use to build a company profile.

A common mistake: shipping one version of Organization on the home page and a slightly different one on the About page. When crawlers see two inconsistent entity descriptions, trust drops. Pull the schema into a single shared object and reference it everywhere.

The Organization block has to agree with what a human can actually see on the site. Entity Signals for Company Websites covers the page side of the same equation. Schema saying "team of 50" while the team page lists eight people is a GEO signal you don't want.

WebSite #

WebSite is short but worth its own section. The minimum useful version has two fields:

• name: the site's display name (not necessarily the company name — could be brand + " | Insights").
• potentialAction: the markup for an in-site search box. With this configured, branded SERP results may show a sitelinks searchbox.

If your site has no real search feature, skip it. Don't fake a search action just to chase a rich result. Google's spam team flags that pattern, and it's exactly the kind of "fake schema" that erodes trust over time.

Article #

Blog posts and editorial pages should use Article or BlogPosting (the latter inherits from the former and is more accurate for blogs). This is the highest-ROI schema type. The spec is mature, Google's documentation is clear, and rich-result eligibility is reliable.

Required:

• headline: matches the H1 on the page, under 60 characters.
• image: at least one, ideally three at different aspect ratios (16:9, 4:3, 1:1) so Google Discover has options.
• datePublished, dateModified: ISO 8601. Update dateModified only when you've genuinely revised content. Bulk-touching it to "look fresh" is a red flag.
• author: a Person or Organization. If you go with Person, link to a real /authors/xxx/ page with a bio. That's what closes the E-E-A-T loop.

Strongly recommended:

• publisher: should match the home page's Organization block.
• mainEntityOfPage: the canonical URL of this page.

Common Article mistakes: clever headlines that don't include the actual topic; one stretched cover image; dateModified that always equals datePublished (which tells Google nothing has ever been maintained).

Service #

This is the part that matters most for service businesses. Every standalone service page should ship Service schema. The fields aren't as standardized as Article's, but a complete block measurably improves AI citation rates.

Recommended fields:

• name: the service name, matching the H1. "Overseas website launch and SEO/GEO support" is more useful than "Web development".
• provider: a reference back to your Organization.
• serviceType: a category. Useful for AI engines doing taxonomy.
• areaServed: countries or regions. For an exporter, this is non-negotiable. List Germany, United States, Southeast Asia, etc.
• description: one sentence covering the audience, the problem, and the approach. The page's meta description usually works.
• offers: if you publish pricing or a starting point, use Offer. If pricing is on inquiry, omit it. Never put a fake price in just to populate the field.
• hasOfferCatalog: list the sub-services under this page.

For example, our /solutions/going-global-it page carries roughly:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Overseas website build with SEO/GEO support",
  "provider": { "@id": "https://mansion.tech/#organization" },
  "serviceType": "Website Development",
  "areaServed": ["Germany", "United States", "Southeast Asia"],
  "description": "End-to-end overseas website builds for Chinese exporters — domain, hosting, content, SEO/GEO setup, and post-launch optimization.",
  "url": "https://mansion.tech/solutions/going-global-it"
}

The most underused field is areaServed. When a buyer in Frankfurt searches "wordpress development agency Germany", search engines preferentially match suppliers who explicitly declare service coverage. Skipping areaServed doesn't hurt rankings, but it does drop you out of the candidate set for geographically scoped queries.

FAQ #

FAQ schema is the most argued-about type. In 2023 Google narrowed FAQ rich results to authoritative medical and government sites. Most sites don't see FAQ accordions in the SERP anymore.

That doesn't make FAQ schema useless. It's still structured Q&A data, and AI summarizers (Overviews, Perplexity, ChatGPT) preferentially digest structured Q&As when crawling. The success metric just shifted. It's no longer about Google rich results; it's about AI citations.

Rules of thumb:

• Required: every Q&A in the schema must also be visible in the page HTML, word for word.
• Reasonable: 3–6 Q&As per page, covering questions a real buyer asks during procurement (price, delivery, case studies, industry fit, risk).
• Don't: dress up keyword lists as questions; copy the same FAQ block site-wide (Google flags this as templated abuse); fake-question your way through ("What is a website?" — please don't).

How to Write Answer-Ready Service Pages goes deeper on the actual phrasing. Schema is the wrapper; the question wording does the real work.

Vue and WordPress #

The maintenance pattern differs by stack.

Vue / Nuxt: attach a <script type="application/ld+json"> block per page component. In Nuxt, use useHead or the community nuxt-schema-org module. Both render schema during SSR, so crawlers receive it in the initial HTML. In SPA mode, make sure schema is in the first response payload, not injected on mounted. Googlebot renders JS but doesn't always wait for full hydration.

WordPress:

• Yoast or Rank Math will auto-generate Organization, WebSite, Article, and BreadcrumbList out of the box.
• Service schema is rarely auto-generated. Either hand-write it in a Custom HTML block on each service page, or use a paid plugin like Schema Pro.
• For FAQ, use the Gutenberg FAQ block or a dedicated FAQ schema plugin. Don't paste raw JSON-LD into post content; theme updates can wipe it out.

Either way, schema must be in the HTML source, not injected by client-side JS after onload. Google's JSON-LD policy doc recommends JSON-LD over Microdata or RDFa precisely because JSON-LD lives in <head>, decoupled from layout, easy to maintain.

Pre-launch QA #

Run these three checks after every deployment that touches schema:

1. Rich Results Test: paste the URL into search.google.com/test/rich-results to see what Google actually parses, and which warnings or errors fire.
2. Schema Markup Validator: validator.schema.org checks compliance against the full schema.org spec. Useful because AI engines often consume more types than Google's rich-result whitelist.
3. Search Console → Enhancements: a week after launch, check the Article, FAQ, Product, and Breadcrumb panels for errors. Fix errors immediately; warnings can be triaged.

If you only run one tool, run Rich Results Test. It tells you what Google actually accepted, which matters more than what's "technically correct".

Common mistakes #

Ranked roughly by how often we see them in audits:

• FAQ abuse: stuffing self-promotional fluff into Q&As ("Are you a professional team?"). Google's spam team handles this aggressively.
• Schema/page mismatch: questions that exist in JSON-LD but not in the visible HTML. Once flagged, the entire page's schema trust takes a hit.
• sameAs linking to dead profiles: LinkedIn pages closed but still referenced; Douyin or WeChat URLs that crawlers can't resolve.
• dateModified mass-refresh: changing timestamps on all articles to fake recency. Google compares actual diffs, this never works.
• Inconsistent Organization across pages: home says 50 employees, About schema says 30, LinkedIn says 100. AI summaries pick the lowest number or skip the citation entirely.

For a fuller audit framework, see SEO/GEO Audit Sample Report. Schema is one of its standard sections.

Priority #

Don't try to ship every type on day one. A reasonable order:

P0 — must-ship at launch

• Home + About: Organization + WebSite
• Every service page: Service
• Every blog post: Article / BlogPosting
• All pages: BreadcrumbList (most SEO plugins handle this)

P1 — within two weeks of launch

• Service pages: 3–6 real Q&As plus FAQ schema
• Case studies: Article or CaseStudy (the latter is newer but recognized by major AI engines)
• Team pages: Person schema for key authors and consultants

Optional — judged case by case

• Product: only if you genuinely sell a productized SKU. Don't force it onto a service page.
• Review / AggregateRating: only with verifiable review sources. No fabrication.
• Event, Course, JobPosting: when the content actually fits.

If your site hasn't yet cleared the basics in Technical SEO Baseline for a New or Rebuilt Website (crawl, indexing, performance), fix those first. Schema is downstream of those.

Questions #

How long until structured data shows results? #

Crawl and re-index typically takes one to three weeks. Rich-result appearance in the SERP is a separate question. Article and BreadcrumbList are reliable; Service and FAQ depend on Google's current display rules. AI citation likelihood, though, starts rising the moment schema ships, because tools like ChatGPT and Perplexity actively prefer structured data when crawling.

Are Yoast or Rank Math defaults enough? #

For an editorial blog, yes. For a service business, no. Neither plugin auto-generates Service schema or fills in business-specific fields like areaServed or offers. Service pages and case studies need to be hand-tuned.

What if we don't have LinkedIn or X yet? #

Better to omit sameAs than fill it with fake profiles. That said, opening at least a LinkedIn company page and an X Professional Account is worth the hour. See How to Set Up an X Professional Account for a B2B Brand for the setup. A complete sameAs block measurably improves entity confidence.

How does FAQ schema relate to "AI Overviews optimization"? #

FAQ schema gives AI summarizers structured Q&A data, which they preferentially digest. But citation isn't decided by the schema itself. It's decided by how clearly the answer is phrased and how verifiable the data is. Schema is the wrapper that makes the content easier to read; quality is what makes AI choose you over the next site.

Get a diagnosis #

If your site is live but Search Console → Enhancements is empty, or you suspect the service-page schema is missing fields you can't quite name, bring your domain and the URLs of your two or three most important service pages. We'll run Rich Results Test and Schema Markup Validator with you in a free initial review under our overseas website build and SEO/GEO support service, and tell you which items are P0 fixes and which can wait until next quarter.