For a decade or so, schema markup has been sold as a means to gain rich snippets in search results. ‘Rich snippets’ are bits of extra information found in search results pages (SERPs) that can be added to a website to enable additional text to be displayed. Such information could be ratings for a business or extra description regarding articles and other content types on a website. These have historically been sold as ‘SEO tricks’ and as additional click-through rates in search engine results pages. Unfortunately for all of us, though, Google removed all the rich results for FAQ pages, how-to guides, and a number of other content types from the search results some time ago without prior warning and without explanation. They were removed in May 2026, so I appreciate that it’s taken until now for the full extent of the damage to become apparent.
However, while rich snippets have traditionally been used as a way to gain a “nice to have” in search (a star rating here and there), events of the last year or so have seen them stripped from search engine results pages (SERPs) left and right. And Google has been stripping rich results from schema types left and right too. Most recently it was the FAQ-rich result that got stripped from search results. Which got me thinking: do we even bother with schema markup? The answer is yes. But not for the reasons you’d expect.
This is the shift MyAibo works with clients on constantly: moving schema markup from an SEO afterthought to a genuine translation layer between your website’s architecture and the logic an AI system uses to understand it. Here’s how to actually do that.
From decoration to a blueprint for AI. How to move beyond basic metadata
Most websites with schema markup have isolated bits of code that are used to define the structure and context of individual pages on the site. For instance, every one of the blog posts on this website would be tagged as an article object, and the contact page would be tagged as a local business object. While the use of schema markup on individual pages helps AI-powered systems to better understand individual web pages, it does not help these systems to understand the structure or relationships of individual websites. Moreover, a great deal of schema markup on individual web pages defines entities that are associated with a website, such as the business that a website represents and the people that work for that business.
Google’s removal of FAQ rich results from search results in May 2026 brought to light the point previously made about the removal of HowTo results in 2023. The rich snippet was never the goal of schema markup. The goal was and continues to be to provide search engines with a website’s pages that have been translated into a blueprint or map that the search engine can use in order to understand the structure and meaning of the pages on the website. Rich results or search features are created from the structural data that has been embedded into the website’s pages by the use of schema markup. However, this data is used by the search engine in order to provide search results and answer queries. Therefore, as long as the search engine is able to understand the data that has been published by a website, the fact that the data is not creating a rich result in the search engine results pages (SERPs) does not pose a problem to the website.
In the last few sections, we’ve talked about how to add basic metadata to your website to create rich snippets in search results. But if that’s all you know about schema markup, then you’re only scratching the surface of what it can do for you. For example, basic metadata only paints a picture of what a page on your website is about, and therefore, it doesn’t provide any real value to potential customers in terms of describing your business and the range of services you can provide to them. In other words, basic metadata is simply a form of website decoration that can only add extra information to search results and help a page stand out from others in search results.
In this section titled Advanced JSON-LD Schema Markup: Translating Your Website Architecture for AI Crawlers, we will look at how to use advanced JSON-LD schema to add value to your website. First of all, we will look at the differences between the way that basic metadata is used as opposed to advanced JSON-LD schemas. As we have said already, one of the biggest limitations of basic metadata is that it can only paint a picture of what a page is about. As a result, the information that basic metadata adds to a search listing can only be used to describe a page, rather than a business and the services that the business can offer to its customers. In contrast, the primary function of advanced JSON-LD schema is to provide a range of different types of information about a business and the services that it can offer to its customers, which can then be used by a wide variety of different systems. For example, information about an organization and the range of different services that it provides to a particular audience can be used by search engines to provide results to searches that are conducted by potential customers of that organization. Information about the members of an organization can also be used by search engines in order to provide results to searches that are conducted by people who are looking for information about the people who work for a particular organization. Similarly, information about the team members of an organization can also be used by search engines in order to provide results to searches that are conducted by people who are looking for information about the people who work for a particular organization. Therefore, as you can see, advanced JSON-LD schema provides a number of different ways in which a business can be represented online, which can then be used by a wide variety
How AI crawlers actually read a site
As an index of online content, search engines and other tools that index online information for later searching typically index the content of web pages and online information feature by feature and piece by piece, from word to word, from line to line, from image to image, etc. They can process large amounts of online content but are typically slow, relying on more or less accurate statistical models for interpretation. Unlike these indexers of online content, however, newer indexers that support AI-powered searching of online information are typically fast, able to process large amounts of online information quickly. Furthermore, they do not simply index online information feature by feature and piece by piece from online web pages, etc. They can be supplied with and can read structured information from web pages supplied in script tags, such as JSON-LD.
The basic metadata found on most websites are used as decoration for search engine results pages. However, the retrieval systems powering the new AI-powered web crawlers can use the same structured data to understand the pages of websites that these new crawlers are browsing through. In order to achieve this, the basic metadata found on most websites must first be translated into a blueprint that these AI-powered web retrieval systems can use. This means that each page of content on a website must first be translated into a structured format that can be read by the AI-powered systems powering the new web crawlers.
Create a blueprint: Basic to advanced schema markup
This is where most schema implementations fail. While adding an organization tag to a home page and article tags to all of a website’s blog pages is trivial, connecting all of these related facts together to form a single graph or set of related nodes of information on a website is far harder. One of the key skills here is the use of the @id property on all entities to provide a permanent URL that can be used to link to the same piece of information elsewhere on a website.
Of course there’s more to linking AI Search Crawlers to the Web Pages on your Site than to use many types of schema markup, such as local business, organization, department, job, service, person, team, how-to, article, question and answer, FAQ page, etc. The real skill here is then to build an entity graph on your web pages by linking together all of the various schema types on a page using the @id property.
The organization is registered once and has a permanent @id. The Service, Person and WebPage entities only refer to the already declared data and do not repeat it. A crawler can therefore easily traverse the graph and does not have to make any inferences (e.g., Jane Doe works for MyAibo, and MyAibo offers this service). This is in contrast to a website that only describes itself, as opposed to one that also makes this information machine-readable. For a complete list of all available properties for each type, refer to the developer documentation for Schema.org. This is the best place to start when building a large graph of information.
Priority schema types for machine-readable authority
There are a number of Schema.org types where the amount of information to create machine-readable authority for AI-powered visibility of a website is greater than other types of resources on the same website. A sensible order of information creation for a limited set of resources on a website is the following:
Organization - The topmost entity on your website. Define the logo of your company, the same as links to your social media profiles or other verified business listings, and the contact points for your organization. All the other entity types on your website should eventually link back to the ID of this organization entity.
Person—Attach real authors and founders to content using `worksFor` and `author`, linked to the organization. This is the machine-readable version of E-E-A-T: it tells a crawler who is accountable for a claim, not just that a claim exists.
Service / Product — The main type of information that a company wants to put out to the AIs to define the service or product that a company provides to its customers. The main property for this type is the provider of the service or product (provider). The service or product entity is linked to the organization (the root entity of the graph) with the provider property.
Review / AggregateRating—Third-party validation, structured. This is proof-of-authority data, not just decoration.
BreadcrumbList—This defines the site’s hierarchy and thus makes it easy for a crawler to determine a page’s position in a site.
Website (with a)—A single, sitewide declaration that ties the whole graph together under one root entity.
FAQ Page: How To—These are the types of pages that Bing supports as well as services like Perplexity, so it’s better to write the pages in the correct structure and get crawled rather than to try to get featured in Google Search results for a specific query.
Implementation without creating technical debt
Here are a few key points to help avoid building technical debt with entity graphs:
1. Decide the canonical facts before you write any markup. Business name, URL, logo, and social profiles need to be identical everywhere they appear in the schema, on the page, and on third-party listings. Schema doesn’t fix inconsistency; it exposes it.
2. Your markup should match the main content of your page. If someone wrote a post, then you should use markup for a person who works for your organization and is the author of that post. You should use the markup for an AggregateRating only for ratings that you have for the thing the current page is about. In general, AI features’ structured data should match the main visible content on the corresponding page. This is a trust problem, not a technical problem, and can negatively impact your page's performance in AI features’ structured data if there is a mismatch between the visible content on a page and the markup on that page.
3. Template it; don’t hand-write it per page: JSON-LD code should be generated from the same data that’s being used to populate the corresponding web page. If a page requires a number of fields to be filled out in a CMS, then those same fields should be used to generate the corresponding JSON-LD. That way the JSON-LD is guaranteed to always match the corresponding web page, and there’s no risk of it becoming outdated.
4. Validate your work. Use Google’s Rich Results Test and the Schema Markup Validator to check your work before it goes live. This will prevent mistakes in your markup that can be problematic for search engines to process. Note that the Rich Results Test is currently not supporting the FAQ-specific reporting, which is being phased out by mid-2026 as part of the abovementioned deprecation. However, the tool is still very useful for checking the vast majority of other types of structured data on a webpage.
Where the payoff actually shows up
If you create a quality entity graph, then Bing, Perplexity, and the like will create the best overviews for your website, composed of all of the information of relevance to potential customers and prospects. Articles on your site will be appropriately cited by chatbots, etc. Also, as mentioned previously, your organization will receive the appropriate amount of recognition in knowledge panels and, consequently, all search results where your organization’s name appears. It is this type of structured information that enables the end result that is typically referred to by SEO practitioners as ‘structured content’ or, more simply stated, 'SEO.' We at MyAibo have developed our GEO/SEO practice in order to deliver such structured information on behalf of your organization.
In short, the companies that will get cited by the AI-powered search engines over the next couple of years are going to be the ones that have structured their digital assets to clearly and concisely communicate what they are to the search engines. This is going to require more than just tons of additional content; it is going to require a clear understanding of the entity that is being represented and the application of that understanding in the creation of the content that is going to get found by the search engines.