SEO
Structured data for SEO and GEO : helping Google and AI understand a website
Definition
Structured data is a machine-understanding layer.
Structured data is information added to the code of a page to help machines understand more precisely what they are reading : an organisation, an article, an author, a FAQ, a breadcrumb, a product, a person, an event or a service page.
It most often relies on the Schema.org vocabulary, used to describe entities and their relationships. The recommended format for most modern web projects is JSON-LD, because it makes it possible to structure data cleanly without mixing the markup into the visible HTML content.
Its role is not to replace page content. Structured data should confirm, organise and clarify what is already visible to the user. Effective structured data makes a page less ambiguous : who publishes it ? What is the subject ? Who is the author ? What is the date ? Where does the page sit within the website ? What type of content is being presented ?
Useful structured data does not try to manipulate engines. It makes explicit what the website already states clearly.
Approach
Move from decorative markup to a real entity architecture.
At Edikka, structured data is treated as a technical intelligence layer. It should not be added page by page at random. It should form a coherent system between the website, the organisation, authors, articles, categories, breadcrumbs and important pages.
This approach is essential for both SEO and GEO. SEO aims to make the website visible in traditional search engines. GEO, or optimisation for generative engines, mainly requires content to be understandable, contextualised, reliable and connected to clear entities. Structured data does not guarantee that an AI system will cite a page, but it reduces ambiguity.
Entities
02Relationships
03Context
04Validation
Positioning
Structured data does not replace technical SEO, content or authority.
Structured data is often misunderstood. It cannot compensate for weak content, confusing architecture, poor indexation or lack of authority. It is not a magic ranking accelerator.
Its value is more subtle : it helps systems identify more precisely what a page represents. It makes content more readable for engines, supports certain rich results when Google still supports them, and can make a website easier to interpret for AI systems.
Clarify
Precisely identify entities : organisation, author, article, page, FAQ, product or breadcrumb.
Connect
Show relationships between the page, website, author, organisation, categories and content.
Validate
Confirm that visible content and invisible data tell the same story.
Maintain
Keep structured data up to date when content, authors, dates or pages evolve.
Challenge
Why engines need explicit signals.
An engine can read a page, but that does not mean it perfectly interprets all its relationships. It can detect text, a heading, an image or a link, while still needing additional signals to clearly understand the identity of the publisher, the page type, the publication date or the position of the content within the site structure.
Structured data answers this difficulty. It gives machines a shared vocabulary. It makes it possible to express information in an explicit format, instead of forcing the engine to infer context only from visible text.
Identity
The website clearly states which organisation publishes, with which official profiles and identity.
Content
The page specifies whether it is an article, FAQ, web page, product page or service page.
Journey
The breadcrumb clarifies where the page sits within the website structure.
Trust
Authors, dates, publishers, sources and relationships strengthen the overall consistency of the content.
Method
The 10 pillars of a structured data strategy for SEO and GEO.
A professional structured data strategy is not about pasting a few JSON-LD scripts into pages. It requires a clear architecture : which entities exist, which relationships connect them, which data is visible, which pages deserve markup and how coherence will be maintained.
The following pillars make it possible to create a reliable foundation that is useful for Google, traditional search engines, AI engines and tools that use the web as a structured source.
Entities
Identify the main entities of the website
Before adding schema, the important entities must be mapped. A professional website does not only contain pages : it contains an organisation, authors, categories, articles, services, offers and sometimes products, locations, events or resources.
- Organisation publishing the website
- Website and main pages
- Authors, founders or identifiable experts
- Articles, insights, guides or news content
- Categories, pillar pages and breadcrumbs
- Visible FAQs on certain pages
- Services, offers, products or business content depending on context
Organization
Structure the identity of the organisation
The Organization schema clarifies the identity of the entity that publishes the website : name, logo, URL, official profiles, public contact details, founder, brand or institutional information when these details are relevant.
The organisation should be described once in a coherent way, then reused across other schemas through a stable identifier.
- Use a stable
@idfor the organisation - Declare the official name and main URL
- Add the logo in a clean and accessible format
- Connect official profiles with
sameAswhen relevant - Avoid unverifiable, outdated or purely promotional information
WebSite & WebPage
Give the website and its pages a clear framework
The WebSite and WebPage types make it possible to structure the website and its pages as distinct objects. They help express the relationship between a page, the website it belongs to and the organisation that publishes it.
Represents the website as a whole : its name, URL and publisher.
Represents a specific page with its URL, title, description and place within the website.
Connects a page to the website it belongs to.
Connects the content to the organisation that edits or publishes it.
Article
Structure articles, insights and editorial content
The Article schema, or variants such as BlogPosting depending on the context, describes editorial content : title, description, author, publisher, image, publication date, modification date and main page.
For a website like Edikka, this markup is strategic. It clarifies that insights are structured editorial content, connected to an organisation, an author or an expertise, and integrated into a content architecture.
headlineconsistent with the visible titledescriptionaligned with the introduction or article promiseauthoridentifiable when editorial expertise should be carriedpublisherconnected to the organisation- Reliable
datePublishedanddateModified - Relevant, accessible and high-quality
image mainEntityOfPageconnected to the article canonical URL
Breadcrumb
Clarify hierarchy with BreadcrumbList
The BreadcrumbList schema describes the breadcrumb of a page. It indicates the position of the page in the structure and helps clarify the relationship between homepage, categories, subcategories and final content.
The trail should follow the real hierarchy of the website, from the homepage to the current page.
The markup should match the breadcrumb or structure actually presented to the user.
Breadcrumb items should point to clean, indexable URLs consistent with navigation.
FAQ
Use FAQPage only when the FAQ is genuinely visible and useful
The FAQPage schema remains a valid Schema.org type when a page genuinely contains a list of questions and answers. But it should no longer be treated as an automatic rich-result lever in Google, since FAQ rich results are no longer displayed in Google Search as of May 2026.
The right approach is to keep a FAQ when it brings genuine user value : clarification, reassurance, answers to objections or links towards more complete content. The markup should describe the visible FAQ, not create an invisible layer of artificial questions.
- Questions and answers must be visible on the page
- Each answer must be short, useful and faithful to the real content
- Avoid FAQs generated only for SEO
- Do not mark up questions that are absent from the page
- Connect answers to useful pages or articles when the topic deserves more depth
Entity graph
Connect schemas together with stable identifiers
An advanced strategy is not limited to adding several independent JSON-LD blocks. It must build a coherent graph : the article is published by the organisation, written by an author, belongs to the website, sits within a page, has a breadcrumb and may contain a visible FAQ.
The best markup does not only describe objects. It describes relationships between objects.
- Create stable
@idvalues for the organisation, website, pages and authors - Reuse the same identifiers instead of recreating different entities
- Connect
Article,WebPage,OrganizationandBreadcrumbList - Avoid contradictory graphs or duplicated entities
- Maintain consistency between JSON-LD, visible HTML, canonical and sitemap
GEO
Prepare the website for AI engines without falling into artificial markup
In a GEO logic, structured data should help generative systems better interpret website content and entities. But it does not guarantee that an AI engine will cite, summarise or recommend a page.
Its role is to improve machine readability : clear identity, typed content, identifiable authors, reliable dates, coherent architecture, useful FAQ and explicit relationships between content.
Clearly identify the company, author, content and page.
Specify content type, role, date and relationship to the website.
Align visible and structured data to avoid contradictory signals.
Connect pillar page, article, author, organisation, category and breadcrumb.
Validation
Test structured data before and after publication
Structured data must be validated technically and editorially. A script can be syntactically valid while remaining inconsistent with visible content. Conversely, useful data may be ignored if it is malformed or contradictory.
Maintenance
Maintain markup over time
Structured data becomes dangerous when it is no longer maintained. An author change, moved page, removed FAQ, modified date or replaced logo can make the markup inconsistent.
- Update modification dates only when a real update has taken place
- Remove FAQ schema when the visible FAQ is removed
- Check URLs in
BreadcrumbListafter a redesign - Maintain the logo, official profiles and organisation information
- Check errors after deployment, migration or template changes
- Document markup rules in the back office or publishing system
Architecture
The ideal model : a coherent graph, not isolated schemas.
A high-level structured data strategy should work like a graph. The organisation is the central entity. The website belongs to it. Each page is part of the website. Each article is published by the organisation, potentially written by an author, classified in a structure and connected to its breadcrumb.
This model gives the website overall coherence. It avoids repetition, contradictions and orphan entities. It is especially useful for editorial websites, expertise websites, agencies, catalogues and platforms rich in content.
Organization, WebSite, WebPage, Article.
The publishing entity : name, URL, logo, official profiles and brand identity.
The main website, connected to the organisation and used as the global framework.
The current page, connected to the website, breadcrumb and main content.
The editorial content, connected to its author, publisher, dates, image and canonical page.
Concrete example
Concrete example : a properly marked-up Edikka article.
The goal is not to show a complete JSON-LD implementation, but to make the principle visible : a graph connects important entities with stable @id values.
Organization declares the Edikka entity, WebSite points to that organisation, then Article receives its canonical identifier and headline.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://www.edikka.com/#organization",
"name": "Edikka",
"url": "https://www.edikka.com"
},
{
"@type": "WebSite",
"@id": "https://www.edikka.com/#website",
"url": "https://www.edikka.com",
"publisher": {
"@id": "https://www.edikka.com/#organization"
}
},
{
"@type": "Article",
"@id": "https://www.edikka.com/en/insights/seo/structured-data-seo-geo#article",
"headline": "Structured data for SEO and GEO: helping Google and AI understand a website"
}
]
}Use cases
Which schemas should be used depending on the page type ?
Not all pages should receive the same structured data. The right schema depends on the visible content, the page type, the SEO objective and the role of the page within the architecture.
The principle is simple : mark up only what truly exists, with the most specific and useful type.
| Page type | Priority schema | Role |
|---|---|---|
| Homepage | Organization, WebSite, WebPage | Clarify the website identity |
| Article | Article, WebPage, BreadcrumbList | Structure editorial content |
| Category | CollectionPage, BreadcrumbList | Clarify editorial organisation |
| Service page | Service, WebPage, Organization | Explain the offer |
| Author page | Person, ProfilePage | Strengthen expertise |
| Visible FAQ | FAQPage | Describe questions that are actually displayed |
Early signals
Signs that a website lacks coherent structured data.
A lack of structured data does not always create a visible error. It often appears as poor machine readability : unclear identity, unconnected authors, articles without reliable dates, categories that are hard to interpret or missing breadcrumbs.
Articles do not clearly indicate author, publisher, dates or main image.
The website declares several different organisations depending on the template.
The visible breadcrumb and BreadcrumbList do not follow the same hierarchy.
Marked-up FAQs do not exactly match the questions visible on the page.
Modification dates change automatically without a real editorial update.
Structured data is technically valid, but does not tell a coherent story.
Structured FAQ
FAQPage after 2026 : useful for structure, no longer for gaining a Google FAQ display.
The FAQPage schema should be used with more discernment than before. Since May 7, 2026, FAQ rich results are no longer displayed in Google Search. A FAQ strategy should therefore no longer be built to gain extra space in the results.
However, a visible, useful and well-structured FAQ remains relevant for user experience, reassurance, internal search, internal linking and understanding recurring questions. The markup can describe this FAQ when it genuinely exists on the page.
Useful, visible, validated, connected FAQ.
The FAQ answers real customer questions, not questions invented for SEO.
The marked-up questions and answers are actually displayed on the page.
Answers are accurate, up to date and consistent with the offer or main content.
The FAQ links to useful pages or articles when the answer deserves more depth.
Common mistakes
Mistakes that make structured data useless or risky.
Structured data mistakes often come from an overly mechanical approach. Markup is generated automatically, but it does not always follow visible content, dates, authors, canonical URLs or the rules of each Schema.org type.
The risk is not only invalid code. The deeper risk is creating contradictory signals that weaken the technical trust of the website.
Declaring information that is not present or verifiable in the visible content.
Adding too many Schema types without real usefulness, simply to “do SEO”.
Creating several Organization, author or page entities with different identifiers for the same entity.
Displaying one date on the page, declaring another in JSON-LD, or updating dates without reason.
Declaring a hierarchy that does not match real navigation or canonical URLs.
Adding questions absent from the page or generated only to target search queries.
Prioritisation
Prioritise schemas that reduce the most ambiguity.
Not all schemas have the same value. A professional website should first address fundamental entities : organisation, website, pages, articles, breadcrumbs and genuinely useful FAQs. Other types should be added only when they match visible content.
Priority should go to schemas that clarify identity, editorial structure and the strategic content of the website.
Organization
Clarify company identity, logo, URL, profiles and publisher role.
Article
Structure insights, guides and editorial content with author, publisher, dates and canonical page.
BreadcrumbList
Make page hierarchy more explicit and consistent with the website architecture.
FAQPage
Mark up only real FAQs that are visible, useful and maintained over time.
Validation
The quality control process before publication.
Quality control should check three levels : JSON-LD syntax, conformity with the Schema.org type and coherence with visible content. A technically valid schema can still be poor if it does not properly describe the page.
Validation should be integrated into the publishing workflow, especially for article, category, FAQ and service page templates.
Check that JSON-LD is well formed, without comma, quote or incomplete-object errors.
Check that the properties used match the chosen Schema.org type.
Test supported types with Google tools when the objective concerns Google Search.
Compare markup with visible content : titles, dates, author, FAQ, breadcrumb and URL.
Edikka application
The ideal structure for Edikka insights.
For Edikka, structured data should strengthen editorial credibility and the understanding of expertise. Each insight can be marked up as editorial content connected to the organisation, its author, its category, its breadcrumb and any visible questions.
The goal is not to overload the code, but to make each content piece clearer : which expertise, which article, which date, which category, which relationship with Edikka and which place in the editorial ecosystem.
Edikka, author, insight, category.
A stable Organization, used as the reference publisher across the entire website.
A Person entity when editorial expertise should be associated with an identified author.
An Article or BlogPosting connected to its page, category, dates and image.
A collection or category page connected to the articles it organises.
Governance
Maintain structured data with the same discipline as content.
Structured data must be governed. It should not depend on improvised scripts or fields filled randomly in the back office. Rules must be documented : which schemas, which properties, which pages, which exceptions and which checks before publication.
This governance becomes even more important when the website regularly publishes articles, FAQs, categories, service pages or multilingual content.
Generate schemas from templates rather than rewriting them manually page by page.
Identify mandatory data : title, date, author, image, category, URL and description.
Block or flag schemas that are incomplete, invalid or inconsistent with visible content.
Document schema changes during redesigns, migrations or structural changes.
Workflow
The professional workflow for deploying Schema.org without errors.
The right workflow must connect strategy, technology and content. Structured data should not be added only by a developer, nor decided only by SEO. It requires collaboration between editorial strategy, technology, UX, SEO and website administration.
Deliverables
What a structured data strategy should deliver.
A serious strategy should not deliver only JSON-LD code. It should produce clear documentation, an entity model, maintainable templates, control rules and long-term monitoring.
Entity map
A model of the organisation, website, pages, authors, articles, categories and FAQs.
JSON-LD templates
Clean templates for Organization, Article, BreadcrumbList, WebPage and FAQPage when necessary.
Validation rules
Controls for dates, authors, images, URLs, visible FAQs, canonicals and breadcrumbs.
Monitoring
Error monitoring, documentation changes, Search Console reports and regression tracking.
What works
The principles of a truly professional Schema.org strategy.
The best structured data strategies are sober, coherent and maintained. They do not try to mark up everything possible. They mark up what reduces ambiguity, improves understanding and genuinely matches visible content.
Their strength comes from alignment between HTML, editorial content, canonical URL, breadcrumb, organisation, author, article and JSON-LD data.
Visible, coherent, connected, maintained.
Structured data describes only information present or verifiable on the page.
Markup is aligned with HTML, URLs, dates, authors and breadcrumb.
Entities are connected with stable and reusable identifiers.
Templates and data evolve with the website, content and documentation changes.
Conclusion
Structured data helps engines understand what your website states.
Structured data is an important foundation of modern SEO and visibility in generative environments. It helps clarify entities, relationships, authors, articles, breadcrumbs, visible FAQs and the overall identity of a website.
Its effectiveness depends on coherence. Markup must match visible content, use the right Schema.org types, connect entities together and remain maintained over time. A valid but inconsistent schema can be less useful than a simpler schema that is perfectly aligned.
For Edikka, structured data can become a readability advantage : it strengthens the understanding of insights, categories, the organisation, the author, pillar pages and useful FAQs. It does not guarantee visibility, but it builds a clearer, more reliable and more usable foundation for Google and AI engines.
A professional Schema.org strategy is not about adding code. It is about clearly modelling the entities, content and relationships that help engines better understand the website.
Structured data does not decorate a website. It translates its meaning for engines.
Google and artificial intelligence systems no longer simply read a page. They try to understand what it represents, who is speaking, what the topic is, how content is connected and which information can be used in a reliable answer.
At Edikka, we treat structured data as a strategic readability layer. Schema.org, Article, FAQPage, Organization, BreadcrumbList, WebPage and Person should not be added mechanically. They should precisely reflect the real architecture of the website, its expertise, content, authors, internal relationships and trust signals. This coherence between visible content, HTML structure and machine data is what strengthens understanding by Google, AI engines and answer systems.
Make engines understand what the page really is
A page can be an article, FAQ, service page, product sheet, category, author page or organisation page. Structured data should help engines identify that role without ambiguity. Good markup does not replace visible content: it confirms it, clarifies it and makes it easier to interpret.
Connect content, entities and trust signals
Structured data becomes powerful when it describes a coherent ecosystem: an identifiable organisation, articles connected to a category, clean breadcrumbs, FAQs linked to the right topic, credible authors or founders and pages that support one another. Modern SEO does not rely only on isolated pages, but on connected entities.
Prepare the website for answer engines and AI visibility
AI systems need clear, structured and verifiable sources. Coherent markup helps identify the topic, author, organisation, date, hierarchy and available answers. The objective is not only to obtain a rich result: it is to make the website more readable, more reliable and more citable in augmented search environments.
Structured data for SEO and GEO is not a secondary technical layer. It is a clarification language between your website, Google and artificial intelligence systems. Its value depends on one thing: coherence between what the page shows, what the HTML structures and what the JSON-LD declares.
Go further on this topic
Additional answers to clarify the key points covered in this article.
