STRUCTURED DATA
Harder than inserting schema is keeping the inserted values correct. We declare business name, contacts, services and Q&A in JSON-LD, and bind the source to one place so screen and schema read the same value — removing the state where one of them quietly goes stale.
In one paragraph
Structured data is the work of restating facts already written on screen as JSON-LD so machines read them without guessing. We spend more time organising where the values come from than inserting schema code. First the confirmed facts are gathered in one place; then they are declared in order — organisation, then page hierarchy, then questions and answers — and screen and schema are bound to read that one place together. The purpose is that when a value changes, the two do not diverge.
That said, structured data is not a device that guarantees visibility or citation. Google itself describes it in its documentation as an aid rather than a requirement. Insert it accurately and conveying facts gets easier; insert a value that differs from the screen and you have supplied two different facts, which is worse than not having it.
Last verified
WHEN YOU NEED THIS
These are the situations we hear repeatedly in consultations. If any of them apply, start by measuring.
Fixing the screen and forgetting the schema repeats for as long as a site is operated. When the two disagree, a machine receives two different facts about the same company and neither is easy to rely on.
The effect of structured data comes from accuracy of values rather than number of types. Declaring one piece of organisation information accurately beats layering on a type that does not match the page.
Without a fixed identifier for the organisation and a list of official channels, a machine has no basis for connecting them. We define the organisation once with an @id and attach only confirmed channels via sameAs.
Errors are reported only by type and field name, which does not lead directly to which value on which page. Without a table recording what was inserted where and why, every fix means reading the code from scratch again.
WHAT WE DO
Written as units of work rather than abstract proposals. The scope of an engagement is set from this list.
The values that go into the schema get gathered and settled in one place first. Most of schema work is not code but deciding what the confirmed facts about the company are.
It goes first because it is the foundation for a brand being recognised as one entity. Defined once for the whole site, with other schemas referring to that identifier.
BreadcrumbList tells a machine where a page sits, and that URL is matched character for character with the rest of the site. One differing trailing slash is a different URL to a machine.
FAQPage pairs a question with an answer, which makes it easy for an answer engine to cite as-is. It has to be an FAQ that is actually visible on screen, though — an FAQ existing only in schema is a policy violation.
From here we add only what matches the page. The purpose is not to increase the number of types but to declare the shape of the facts the page actually contains.
Insert without validating and you cannot confirm what you inserted. Schema breaking quietly while a site is edited is common, so we hand over the validation points and the list of things to update together.
PROCESS
What you receive at each stage is stated alongside it. Durations are the working time Navirang controls; they are not a promise about when results appear.
We check the schema already in place with validation tools and list the items that disagree with the screen, the duplicate declarations and the broken syntax first.
Current schema checklist
Business name, contacts, address, official channels and the one-sentence definition get settled. Values needing client confirmation are gathered at this stage.
Fact ledger (the schema source)
We map which types go on which page type. The priority runs organisation → BreadcrumbList → FAQPage, and what follows is decided by page character.
Page type × schema type map
JSON-LD is applied and the value sources bound to one place so screen and schema read the same data. The duration varies with site size and the number of page types.
Applied JSON-LD
We confirm recognition with validation tools, then look again at valid and error counts in Search Console once indexing refreshes. We check periodically that site edits have not broken the schema.
Validation results
DELIVERABLES
We do not do work that ends in conversation. The documents below remain, and become the baseline for the next measurement.
The state of the structured data already in place, item by item — separating what disagrees with the screen, what is declared twice, and what has syntax errors.
The settled version of every value going into the schema. Screen, JSON-LD and llms.txt all take this document as their reference.
Which schema goes on which page and why that type. Types deliberately not used are recorded with the reason.
The schema actually applied per page and where it is inserted. Organised so it can be handed over intact even if the development agency changes.
What the validation tools returned, and the list of things to fix together when a value changes. llms.txt is not generated automatically, so it is on that list.
AggregateRating and Review are not included, because there are no actual reviews to display on screen. Google does not present self-authored reviews of one's own service as rich results, and we apply the same standard to client sites.
HOW IT CONNECTS
Our work moves as one piece. SEO builds the foundation for being found by search engines, AEO raises the odds of that information being cited in an answer, structured data helps machines understand the facts, and content supplies the evidence there is to cite.
| Area | Relationship to this work |
|---|---|
| AEO audit | The step that measures which facts are missing on the machine side first |
| Citable content design | Making the sentences themselves citable — schema does not substitute for a sentence |
| AI crawler optimization | The technical work of opening access so a crawler can actually read the declared schema |
| Entity SEO | Aligning notation on channels outside the schema so the organisation reads as one entity |
| Citation monitoring | Re-measuring under the same conditions whether answer content changes after implementation |
| AEO by industry | Aligning industry-specific official registries with the facts on screen |
FAQ
A It is not guaranteed. Structured data is not a device that produces visibility but an aid that helps machines read existing facts without ambiguity, and Google describes it in its documentation as an aid rather than a requirement. Accurate values reduce the chance of company name, contacts or service scope being conveyed wrongly; citation itself depends far more on whether there is a document that answers the question.
A The organisation schema. It is defined once for the whole site with the other schemas referring to that identifier, so if it is wrong everything added afterwards wobbles (with a physical location, a LocalBusiness family type such as ProfessionalService applies). Next comes BreadcrumbList for page position, then FAQPage for paired questions and answers. After that, only types matching the shape of facts the page actually contains — and the types deliberately excluded are recorded in the map with their reason.
A It proceeds one of two ways depending on access. With access to the admin or the code, we insert it and complete the validation ourselves. Where access is closed, we hand over the full JSON-LD per page, where to insert it, and how to verify, in a form the agency can apply directly — and we do the validation once it is in. Hosted builders vary by whether a script can be placed in the head or footer, so that gets checked during the assessment.
A The purpose changed; the reason remains. Google ended FAQ rich result display in May 2026 and took the related documentation down. But FAQPage is data with questions paired to answers, which is a shape answer engines cite readily, and that is the purpose we add it for rather than decorating a search result. It still has to be an FAQ that is actually visible on screen.
A Only when there are reviews actually displayed on screen. Declaring a rating in schema that is not on the site is a policy violation, and Google does not treat a review of your own service written by yourself as a rich result. We hold this line even when asked, and instead look together at which facts with visible evidence on screen can be declared.
A As an optional item. llms.txt is not an official standard, Google states it does not use it in search, and there is no official confirmation from other major engines. That said, one file costs almost nothing and writing it has the side effect of settling a one-sentence definition and a list of core pages, so we include it where it is wanted. It is not generated automatically, so it goes on the list of things to keep updated.
A We validate first. What comes up most in practice is items disagreeing with the screen, URLs with mixed trailing slashes, and the same organisation declared differently on different pages. If the assessment finds no problems it stays as it is; fixing or removing incorrect declarations is the extent of the work.
Send us a URL and we will assess the structured data in place, then list what disagrees with the screen and which types to apply first.
We reply within one business day.