How to Use SEO Structured Data: Common Markup Types and Implementation Methods

The purpose of SEO structured data is to describe the entities on a webpage and the relationships between them in a machine-readable format—for example, whether a page is about an article, a product, or a breadcrumb trail. Search engines can use this information to help understand the content. Pages that meet specific requirements may also be eligible for rich results, but adding markup does not guarantee special presentation or directly guarantee improved rankings.

The most important consideration during implementation is not “how many fields can be marked up,” but what the page actually displays, what you want search engines to understand, and whether the target search engine supports the corresponding search presentation. In a Spanish-language context, datos estructurados SEO refers to this same approach to applying structured data.

First, distinguish markup types from eligibility for search features

Schema.org provides a vocabulary for describing webpage content, such as Article, Product, and Organization. JSON-LD and Microdata are formats for encoding that vocabulary. Google recommends JSON-LD because it can usually be placed separately in the page code, making it easier to maintain without having to rewrite individual content tags on the page.

The fact that a type exists in Schema.org does not mean Google will necessarily provide a rich result for it. Before implementation, consult both the Schema.org type definitions and the documentation for the corresponding feature in Google Search Central to confirm required properties, recommended properties, and content policies. Even if a testing tool reports that the markup is valid, the search engine ultimately decides whether to display it based on factors such as page quality and the query.

Where to use common markup types

Article: Article and news pages. It can identify information such as the headline, author, publication date, modification date, and images. The article page must display the corresponding content, and dates should match what is shown on the page and the actual modification history. Do not change only the date in the markup to make an old article appear fresh.

For example, if a page contains a feature titled Research on Measures to Improve the Execution Rate of Fiscal Budgets in Public Institutions, choose a type based on the content the page actually contains. If it is a complete article, Article may be appropriate; the link title alone is not enough to determine whether the destination page is suitable for a particular type of markup.

Product: Pages for specific products. This type is suitable for pages that display information about a clearly identified product and can describe details such as its name, image, and brand. If a genuine price is available, Offer can also describe the price, currency, and availability. An inquiry-based website with no publicly listed prices should not provide fictitious prices or turn “contact us for pricing” into a specific amount. Product search features have different property requirements; if information such as price is missing, do not assume the page is eligible for the corresponding rich results.

Organization: Business identity information. This type is suitable for the homepage or a representative page about the business. It can describe the business name, website, logo, and publicly available contact details. It helps search engines understand the organization behind a website, but does not mean the business information will necessarily appear in a knowledge panel. For multilingual websites, ensure the business name, website, and contact details are consistent.

BreadcrumbList: Breadcrumb navigation. This type expresses a page’s position in the website hierarchy, such as “Home—Product Category—Product Details.” The markup order should match the navigation visible to users, and each node’s link should point to the corresponding page. Do not create nonexistent hierarchy levels just to add keywords.

FAQPage: Question-and-answer content. Use this type only when the page actually contains the corresponding questions and answers. Google has strict limits on the availability of FAQ rich results, so even if an ordinary commercial website adds valid markup, it should not be treated as a reliable way to obtain expandable question-and-answer results. Check Google’s latest eligibility guidelines before implementation.

Implementing JSON-LD: mapping page content to code

For an article page, first verify the headline, author, date, and image already displayed on the page, then map them to the corresponding properties. The example below is simplified; the URL, dates, and name are illustrative and must be replaced with real page information before publication:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Industrial Equipment Maintenance Guide",
  "author": {
    "@type": "Organization",
    "name": "Example Company"
  },
  "datePublished": "2025-01-10",
  "dateModified": "2025-02-15",
  "image": "https://example.com/images/guide.jpg"
}
</script>

This code can be placed in the page’s HTML head or body. When using a website-building system, first check whether it already has a structured data feature. If the system generates Article markup automatically, inserting another Article with conflicting content may make the page information difficult to interpret. Templates used in bulk should retrieve real fields from the content management system rather than assigning every article the same headline, author, or date.

JSON-LD allows multiple markup types to describe the same page. For example, Article can describe the article content, while BreadcrumbList describes the navigation. Each markup type should serve its own purpose. When the same entity appears more than once, properties such as its name and URL should be consistent. Do not put the prices of every product on the website into the homepage, or mislabel a category listing page as a single product detail page.

How to check and maintain markup after launch

When checking markup, first inspect the final page code and confirm that the markup loads with the page and that search engines can access the page and its related resources. For markup injected through JavaScript, also check that it is present after rendering and that its content is complete. A successful local preview does not mean the live version is working.

Then use Google’s Rich Results Test to check supported rich result types. You can also use the Schema Markup Validator to check the structure of Schema.org markup. The tools serve different purposes: the former focuses on search features supported by Google, while the latter checks vocabulary and structure and does not prove that a page meets Google’s display requirements. During testing, address errors and assess whether any missing recommended fields can be added based on the actual page content.

After publishing the page and allowing it to be crawled, use the URL Inspection tool in Google Search Console to check whether Google can access it. If reports for the relevant features are available, review the detected items and errors. The absence of a report or changes in search results does not necessarily mean the code is invalid: reports and display are both affected by supported types, crawl status, and the search engine’s assessment.

The key maintenance task is to keep the data in sync with changes to the page. When a product is discontinued, promptly update the page display and availability markup. When prices change, ensure the currency and amount match. For multilingual pages, use the name and content actually displayed in that language version, along with its corresponding URL. Removing reviews, offers, or questions and answers that are no longer on the page is more important than keeping syntactically correct markup that no longer reflects the content.