Entity SEO and Schema

Connect business facts clearly.

Help your customers find the right business or branch and check what it offers. We start with names, contact details and service coverage your team approves, then agree the work needed to align pages and structured descriptions.

See what this covers

Where customers can get the wrong picture.

These are possible problems we check for, not findings from a client audit. We start with your customer’s question, then check the facts behind the answer.

01

Branch details disagree across pages.

We compare branch pages, contact pages and relevant profiles with owner-approved names, addresses, phone numbers, hours and service coverage. A directory entry is not automatically authoritative.

02

The customer reaches the wrong branch.

The page should show which branch handles each service and link it from relevant service pages. Each branch keeps its own service facts, separate from the wider organisation.

03

Markup describes facts missing from the page.

Structured descriptions should agree with what customers can read. Unsupported locations, services or relationships should not be added only in code.

04

Valid schema is mistaken for a promised citation.

Schema.org vocabulary and Google-supported features differ. Valid markup does not create authority or guarantee a rich result or AI citation.

Make the next decision easier.

An approved fact sheet gives your pages and markup one source for the business, its services and branches.

01

Agree the branch facts before markup.

Your branch owner confirms names, contact details, hours and service coverage before markup describes them. We record sources and unresolved conflicts so the next decision uses approved facts.

Customer questionRecorded conditionsSourcesNext check recorded
02

Connect the branch to relevant pages.

The page relationship map shows how customers can reach the branch that provides a service, with one consistent reference for that branch across relevant pages.

Approved factsPage taskReviewer
03

Validate descriptions against visible facts.

We compare each field with approved visible facts and the relevant feature guidance. A markup check does not decide what Google displays.

StartDated record
ReviewRepeat check
NextLimits

Follow one customer question through the review.

We follow a customer question through approved business facts, relevant page relationships and structured descriptions. Your team confirms the facts and names the owner of any agreed changes.

Equipment-servicing components and an unlabeled location map prepared for branch-service planning.
  1. 01Establish the branch-service question.

    We record what a useful answer must establish: the relevant branch, correct contact details and confirmation that it provides the service.

  2. 02Confirm the branch facts.

    Ask the branch owner to verify name, address, phone, hours and service coverage. Record conflicting sources before deciding what to change.

  3. 03Connect the relevant pages.

    Link the branch from contact and appropriate service pages. Keep branch facts separate from organisation-wide information.

  4. 04Describe the visible facts in code.

    Use suitable schema vocabulary and consistent references. JSON-LD is one way to describe the facts; it must agree with the page.

  5. 05Validate and name who keeps facts current.

    Compare any implementation with approved visible information and relevant feature requirements. Agree who keeps the facts current; ongoing maintenance is not automatic.

Illustrative work scenario; not a client meeting or captured AI answer.

Agree what this review covers.

Open each area to see a possible scope. We agree available evidence, outputs, responsibility and limits with you before work starts.

01

Possible scope 1

Sourced branch fact sheet

Compare branch details with the owner-approved name, address, phone, hours and coverage.

See what this covers

We record sources and conflicts without treating a directory as authoritative.

  • Possible output: a fact sheet with sources.
02

Possible scope 2

Page and profile correction list

Identify corrections on branch, contact, service and profile pages.

See what this covers

For each correction, we agree who can change the source and who keeps the facts current.

  • Possible output: a correction list with owners.
03

Possible scope 3

Branch and organisation relationships

Link a branch from appropriate contact and service pages.

See what this covers

Each branch keeps distinct facts and one consistent reference across relevant pages.

  • Possible output: a page relationship map.
04

Possible scope 4

JSON-LD markup and validation

Describe visible facts using an appropriate type and validate the implementation.

See what this covers

We compare fields with visible approved facts and relevant feature rules; a passing test does not prove factual accuracy.

  • Possible output: a markup plan or separately agreed implementation.

Keep the question, evidence and next step connected.

This is the proposed order of work. Your agreed scope names who handles each step.

  1. 01

    Confirm names, contact details and coverage.

    We gather facts from the relevant pages and profiles; your approver confirms them. Unresolved conflicts remain on the list instead of going into code.

  2. 02

    Connect the branch and service pages.

    Once facts are approved, we map which pages should mention and link each branch. The named implementation owner makes any agreed edits.

  3. 03

    Validate markup against the approved page.

    Markup follows the approved visible page. We check it against the relevant guidance and record unavailable checks; implementation remains conditional.

See how the question becomes a practical task.

Open the three steps below to see one customer question, the evidence needed and a possible next task. This is an illustrative walkthrough, not a captured answer or client result.

Illustrative working example · Business facts and page relationships

Entity and schema map

We connect approved business facts with their visible pages and suitable markup. For example, a business with several locations may need to distinguish each branch’s contact details from organisation-wide facts.

Customer question

Which location of this business handles my request?

The customer needs the relevant location and correct contact information; structured data describes those same visible facts for machines.

Open each step to see the proposed checks, evidence and possible next task.

01Choose the approved branch facts

Fact sheet

We compare the relevant pages and public profiles with owner-approved names, contact details, hours and service coverage. A directory entry is not automatically the source of truth.

02Connect the branch to the business

Page relationship

We connect the relevant business, services and locations using consistent references and useful page links. Location-specific facts remain distinct from organisation-wide information, and official profiles are linked only where verified and relevant.

03Describe the visible facts accurately

Markup and validation

Schema describes visible business facts in a machine-readable format; JSON-LD is one way to write it. We compare each field with approved page content and the relevant feature requirements. Validation cannot confirm factual accuracy or guarantee a rich result or AI citation. Markup implementation is included only if agreed.

Platform guidance: Google’s structured data guidance.

What this shows: Your agreed scope can provide a sourced fact sheet, correction list and markup plan or agreed implementation. We name who handles each change and who keeps the facts current; ongoing maintenance is not automatic.Illustrative process only. No client result, captured AI response or placement is represented.

Working with Aaron.

Bring the customer question, relevant pages and the person who can confirm the facts. Before starting, agree the scope with Aaron, including who approves changes and who implements them.

Aaron reviewing papers during a discussion.
01

Bring the business context.

Tell us what your customer needs to decide and share the page or answer that concerns you.

02

Identify who can verify the facts.

Name the business owner or subject expert who can confirm branch details, service coverage and scope.

03

Agree implementation and follow-up.

Confirm whether the engagement supplies recommendations, edited pages or implementation, and how follow-up is checked.

Check whether the scope matches your starting point.

Select the statements that describe your situation. This helps frame a discussion; it is not an automated qualification or visibility score.

What can you bring to the work?

Questions about entities and schema.

Short answers on what this work can show, what it cannot, and who does what.

What does schema add?

Schema adds a machine-readable description to facts your visitors can read, such as business names, contact details and hours. It can help Google understand the page and assess its eligibility for supported search features. JSON-LD is one format; markup cannot supply business facts the page does not support.

Does valid schema guarantee a rich result or AI citation?

No. Schema.org vocabulary and Google’s supported search features differ. Valid markup does not guarantee a rich result or AI citation, and Google does not require special schema for its generative AI features. If Google AI answers are your concern, Google AI Overviews is a related, separately scoped service.

How should branches be represented?

Keep each branch’s confirmed contact and service facts distinct from the overall organisation. Link the relevant pages and use consistent references for the same branch.

Is implementation included?

Only if the proposal includes it. We agree whether the work supplies recommendations, revised pages, markup or implementation and name the factual approver and person making changes.

What access is needed?

We can start with relevant public pages and profiles. Agreed Search Console, analytics or site access can add context. We record checks that cannot be performed.

What results are guaranteed?

None. These checks cannot guarantee inclusion, citations, traffic or enquiries. We agree deliverables and how they are reviewed, keeping search observations separate from enquiries and sales.

Must the marked-up facts also appear on the page?

Yes. Google requires structured data to describe relevant visible content. Do not hide extra service areas, reviews or business claims in markup when the page does not support them.

Should every branch use the same contact details?

Use the details that accurately describe each branch. Google’s LocalBusiness guidance covers location-specific information; confirm the appropriate address, phone and hours rather than copying another branch’s facts.

Which tool should check the markup?

Google’s Rich Results Test checks markup for the features it supports. We use the current relevant feature guide and compare each field with the visible page and approved facts. A test result cannot confirm factual accuracy or guarantee display.

When should business markup be reviewed again?

Review it when the visible business facts change, such as a branch move, new opening hours or changed service coverage. Assign someone to update the page and markup together so customers receive consistent information.

A practical starting point

Bring the facts that keep changing.

Share the customer question and the source page or observation that needs attention. Confirm the proposed scope before work begins.

What to expect from a call