The short answer
You need Organization, WebSite, Service and FAQPage, and each one needs a stable @id. The identifier matters more than the volume: without it, every page declares a brand new anonymous business and nothing accumulates.
The detail almost everyone misses
Most sites emit correct, valid schema that still fails to do its job, because every page mints a fresh entity.
Schema uses an @id field as a stable identifier. When your homepage says your organisation is a nameless object, and your about page says the same, and your service page says it again, a machine sees three separate assertions with no way to know they describe one business. Authority spreads thin across all three and compounds on none.
Give the organisation one permanent id, use the same id on every page, and reference it by id everywhere a page needs to mention the business. Now every page is evidence about one thing. This is a small change with an outsized effect and it is the first thing worth fixing.
The four types that matter
- Organization. Who you are. Name, legal name, URL, address, contact details, founding date, a public registration number where you have one, the areas you serve, and sameAs links to your external profiles. This is the anchor everything else hangs from.
- WebSite. The site itself, published by the organisation. Small, but it links the domain to the entity explicitly rather than leaving it implied.
- Service. Each thing you actually sell, as its own node with its own id, a provider pointing back at the organisation, and the areas it is available in. Without this, a model knows a company exists but not what it can be recommended for.
- FAQPage. Question and answer pairs in machine-readable form. This is the most directly extractable structure there is, because it hands a retrieval system a question and a matching answer with no interpretation required.
Getting sameAs right
The sameAs field lists other places on the web that are the same entity. It is how you tell a machine that the company on your site, the company on your professional profile and the company in a public register are one business.
Include a public register entry where your jurisdiction has one, your main professional and social profiles, and any authoritative listing you control. Keep it to profiles that genuinely represent the business and that you keep current. Ten links to abandoned profiles are worse than three to live ones, because inconsistency is the thing you are trying to remove.
What to skip
Do not add schema types that do not describe you. Marking a page up as a Product because Product markup sounds valuable produces contradictions, and contradictions cost more than the missing markup would have.
Do not add aggregate ratings you cannot evidence. Inventing a rating is the fastest way to become a source a system stops trusting, and it is the kind of error that is trivially caught.
Do not chase breadth. Four correct, connected, consistently identified types beat fifteen disconnected ones every time.
And do not treat schema as the whole job. It describes what is on the page. It cannot invent an answer that the page does not contain.
Checking it actually works
Validate the markup, then do the harder check: fetch the page as a crawler and confirm the structured data is present in the HTML that comes back rather than being injected later by JavaScript. Markup that only exists after a browser runs your scripts is markup a retrieval system may never see.
Then check the ids resolve to one entity across the site. View a few different pages and confirm they all reference the same organisation identifier rather than each declaring a new one.