How to use the Article Schema generator?
The tool supports Article, BlogPosting, and NewsArticle, making it suitable for corporate blogs, media outlets, expert sections, and other websites with editorial content. The Article microdata generator outputs the title, author, publication date, images, and other information in JSON-LD format, which search engines can match with the page content.
Working with the generator begins with selecting the content type and entering data that has already been published or will be published on the page. Don't add information just for the sake of a more complete JSON-LD: the structured data should match the actual content of the article, the author's name, dates, and user-accessible images.
After filling out the form, the Article Schema generator generates JSON-LD, which can be verified, copied, and sent to the developer or added via the CMS mechanism. Before implementation, it's worth re-comparing the values in the markup with the page itself, especially if the material has been updated since its initial publication.
1. Select the Article Schema type
Schema.org contains a general Article type and more specific variants for specific publication types. The choice depends on the nature of the content, not on which type seems more SEO-friendly. A corporate article typically uses BlogPosting, an editorial publication might use Article, and a news story might use NewsArticle.
The Article Schema generator should help you choose the most accurate type without artificially complicating the structure. If the publication isn't news content and isn't maintained as a blog post, the generic Article type remains the correct option. The markup type describes the material and doesn't change its purpose for the user.
Article
Article is suitable for informational, analytical, and editorial materials that don't require a more specific classification. For example, it can be used for a comprehensive expert review, industry research, or a publication posted in the website's information section but not formally related to the corporate blog.
This type conveys basic information about the content to the search engine: title, author, images, dates, and other properties. Choosing Article simply for a more general coverage isn't necessary. If the content closely matches BlogPosting or NewsArticle, a more specific type usually describes the page more clearly.
BlogPosting
BlogPosting is designed for blog posts, expert publications, educational materials, and content marketing articles. If a company regularly publishes content in the /blog/ section, and each post has an author, date, and a separate URL, this type typically matches the page structure.
The search terms "blog post schema generator" and "blogposting schema generator" typically lead to tools that work in the same way. The user enters the post data, receives a JSON-LD, and adds it to the page. The section name itself doesn't determine the type; the actual format of the material should be used as a guide.
NewsArticle
NewsArticle is used for news and journalistic publications when the page actually contains news, not just informational text. For such material, correct dates, authorship, images, and consistency between structured data and the information visible to the user are particularly important.
Assigning a NewsArticle to a regular article doesn't provide any additional benefits and may make the markup less accurate. This type also doesn't guarantee inclusion in Google News or the Top Stories section. Search engines evaluate a page based on a combination of technical and content signals.
2. Fill in the article data
After selecting the type, you need to fill in the information that describes the specific publication. The generator's primary fields typically correspond to Schema.org properties and include the title, URL, author, dates, and images. Additional fields can convey the language, site section, publisher, or a brief description of the material.
It's best to only fill in data that can be confirmed by the page content or other user-accessible website elements. If the author is unknown, the last update is missing, or the image is unavailable to search engines, fictitious values won't improve the quality of the structured data.
Article title and URL
The headline property contains the title of the article and should match the title of the published page. There's no need to artificially add additional keywords for the sake of microdata. If the generator includes a description, the description should also accurately convey the content of the article.
The URL is specified for the page described by the Article object. When using mainEntityOfPage, you must specify the correct relationship between the article and its main page. The canonical publication URL, the URL in the markup, and the actual indexed version of the page must be consistent.
Author of the material
The author property helps clearly identify the person or organization responsible for the publication. For expert-authored materials, the Person type is typically used, indicating the author's real name and, if available, a link to their profile, editorial page, or other page with additional information.
For content published on behalf of a company, "Organization" can be used where appropriate. However, replacing the actual author with a brand name just for the sake of filling in a field is not recommended. If a specific professional is referenced on the page, the structured data should retain the same information.
Publication and update dates
datePublished conveys the original publication date, while dateModified conveys the date of the last significant change to the material. These values are useful when an article is regularly updated, but its original date remains part of the publication history and is displayed to the user.
Dates are transmitted using the ISO 8601 format, which is clearly readable by software systems. Don't change dateModified after every minor technical edit to the template or typo correction. The field should reflect the actual content update if the corresponding date is also used on the page.
Article images
The image property should point to an image that is relevant to the publication's content and accessible to search engines. It's best to use a high-quality illustration or photograph that presents the content rather than a random interface element, website icon, or generic company logo.
The image URL must be accessible without authorization or technical blocking. If multiple suitable images are used for an article, Schema.org allows the corresponding dataset to be submitted. However, each image must be relevant to the publication and consistent with what the user sees.
Publisher details
Publisher describes the publisher of the material and typically contains an Organization entity with the company or media name. The structure can also include the organization's URL and logo if this information is relevant to the site and consistent with the overall brand information.
Don't treat the publisher field as a mandatory field. The set of properties used depends on the publication and the available data. The generator should help create accurate markup, not force the user to create values for every possible Schema.org property.
3. Generate JSON-LD
Once the main fields are filled in, the generator converts the entered data into a structured JSON-LD object. Typically, the resulting output is placed inside a structure, which can be added to the page's HTML without changing the article's visible text or its regular markup.
Before copying, it's a good idea to review the author, dates, URLs, and images. If the interface supports both formatted and minified modes, it's easier to read the formatted version for verification. After making changes to the JSON-LD format, it's best to regenerate it to avoid manually correcting the structure.
The article schema generator format typically assumes exactly this scenario: filling out a form, obtaining a JSON-LD, validating it, and then implementing it. Some tools also allow you to download a completed .json file, upload an example, or directly open the result in a structured data validation service.
4. Check the finished markup
Even correctly generated JSON-LD should be checked after creation and again after deployment on a live page. Syntax errors and missing properties can be detected during the generation stage, but after deployment, additional risks arise: conflicts with the CMS, duplicate schema, or an incorrect URL.
Google Rich Results Test and Schema.org Validator are used for verification. After publishing, it's helpful to check the URL itself, not just the copied code fragment. This approach shows the final version of the page that the search robot receives, along with all the template and automatically added structured data.
How does Article Schema affect SEO?
Structured data helps search engines obtain unambiguous information about a publication, including the author, date, images, and type of content. It doesn't replace the text, technical quality of the page, internal linking, or proper indexing, so evaluating Article Schema separately from other SEO elements is inappropriate.
The article schema generator shortens the path from article data to the final JSON-LD, but the result depends on the quality of the source data. If incorrect dates, fictitious authors, or inaccessible images are passed into the code, automatic generation will not correct these errors.
Helps search engines understand the content of a page
A typical HTML page contains many elements, from which a search engine must determine the main content, author, dates, and relationships between entities. Structured data conveys these relationships explicitly and reduces ambiguity during machine processing of the document.
This is especially useful on large sites where a single template is used for thousands of posts. A single Article markup helps maintain a consistent data structure if the CMS correctly displays the headline, author, image, datePublished, and other properties for each page.
May improve article presentation in search results
Correctly structured data can be used by search engines to generate an expanded presentation of materials if the page meets the requirements of a specific search result. The mere presence of JSON-LD does not necessarily mean that the expanded format will appear for every document.
Therefore, don't promise increased CTR or rich results after inserting the code in the generator's text or interface. Search engines independently decide how to display a page, taking into account the quality of the content, data availability, and other factors.
Article Schema is not a direct ranking factor.
Article Schema alone doesn't rank a page higher than a competitor with comparable content. Microdata provides additional structured information and helps search engines interpret the content, but it doesn't replace the relevance of the text or the quality of the website.
From a practical standpoint, issues of indexing, canonicals, internal links, content, and technical errors must first be addressed. After that, structured data adds a machine-readable layer that must remain consistent with the final publication.
Do Top Stories need Article Schema?
Article markup is not a requirement for a publication to appear in Top Stories. Therefore, adding NewsArticle markup just for this block or changing the type of a regular article without a factual basis is not necessary. The type must match the page content, regardless of the intended search format.
At the same time, correct structured data helps search engines retrieve publication data more accurately. For a news website, this is a useful part of the overall technical implementation, but the result also depends on the quality of the content, page accessibility, images, and other factors.
I view Article Schema as an additional data layer for search engines. The more accurately the author, title, dates, images, and other properties in JSON-LD match the actual page, the less ambiguity there is during processing. Therefore, I first tidy up the content and its HTML, and then add structured data. The markup should describe the published page and not create information that the user doesn't see.
Common Article Schema Mistakes
Most issues are not related to JSON syntax, but to discrepancies between structured data and the actual page content. The code may pass basic validation but still contain a different author, an incorrect date, a hidden image, or a publication type that doesn't match the content.
On CMS-based projects, duplication creates an additional risk. One article might be generated by a theme, another by an SEO plugin, and a third added manually by the user. Before implementing a new generator, it's important to understand what structured data already exists on the page.
The markup does not match the visible content.
If JSON-LD conveys one piece of information, but the user sees something else, the markup becomes unreliable. For example, you can't specify a different author, change the publication date, or transmit an image that's completely unrelated to the content and missing from the page context.
Before publishing, it's worth checking the headline, author, image, datePublished, dateModified, and URL. For automated systems, this check can be included in the template or technical checker to prevent errors from spreading to the entire site section.
Incorrect article type selected
The Schema type is chosen based on the actual content format. A typical company manual doesn't become news after selecting NewsArticle, and a static service page doesn't turn into a blog post simply because of the large amount of text.
If you're still unsure between a general and a more specific type, it's best to check the page's purpose within the site structure. Correct semantics are more useful than attempting to use a more specific version without factual justification.
Incorrect dates
Errors occur when datePublished and dateModified are mixed up, generated in different time zones, or automatically changed after each document save. As a result, the search engine receives a date that doesn't match the editorial history of the material.
For a CMS, it's best to store the original publication and major updates separately. If the date is displayed to the reader, it should match the JSON-LD. Values should also be transmitted in a standard format that is clearly recognized by software systems.
The image is not accessible to the search robot.
The image link must point to a truly accessible file. Issues arise due to closed CDNs, temporary URLs, incorrect redirects, indexing restrictions, or image deletion after a page refresh.
You need to check the file address itself, not just how the image displays in the editor's browser. The image should also be relevant to the publication's content. A random logo, decorative icon, or empty placeholder poorly describes the material.
The author is indicated ambiguously
A title like "Admin" or "Editor" without additional context rarely helps clarify who is responsible for the content. If the site publishes expert content, it's better to use the author's real name and a linked profile page with clear information.
At the same time, it's impossible to create fictitious specialists just to improve the data structure. If the materials are actually published by an editorial staff, the actual authorship model must be described and aligned with what the user sees on the page.
There are several conflicting Article Schemas on the page.
Duplicates often appear after adding a new SEO plugin or manually implementing JSON-LD over existing markup. Having two objects isn't always an error, but they should describe different entities and not contradict each other.
If one Article lists the author as Ivan, and another as the company name, or they contain different dates for the same publication, the structure needs to be corrected. Before adding new code, it's a good idea to run a page validator to find all existing objects.
JSON-LD has been updated with fictitious data.
You can't invent authors, dates, ratings, reviews, or publishers just to fill all the generator fields. Structured data must describe the existing content and real entities of the site; otherwise, a formally complete object will convey false information to the search engine.
It's better to leave an inapplicable field blank than to insert a random value. This principle is especially important for automatic generators, where a single incorrect template can create the same error on thousands of URLs.
What we actually did
Dental clinic · Kyiv and Chernihiv
+44% clicks from search
A domain with no history on a website builder. We built the semantic core for both cities, reworked the landing pages and built the link profile from zero. Four months: 34.8k clicks, impressions 1.32 → 1.76M, DR 0 → 41.
E-commerce · international
+96% clicks in two months
A catalog of digital 3D models. We clustered the semantics, rebuilt the hub pages and closed duplicates and indexing errors. Google users 247 → 532, CTR 2.4% → 4%.
Medical center · Ukraine
+68.75% visibility in the first month
Narrow visibility and a small semantic core at the start. Semantics, landing page structure, metadata and internal linking, then gradual link building.
Answers to your questions
What is an Article Schema Generator?
The Article Schema generator creates JSON-LD for an article page based on user input. Typically, the form contains the publication type, headline, author, URL, image, datePublished, dateModified, and publisher information.
After filling in the fields, the article schema generator generates a ready-made Schema.org structure, which can be copied and verified with a validator. The tool reduces the amount of manual technical work, but the user still needs to verify the accuracy of the entered data.
How is Article different from BlogPosting?
Article is a general type for editorial and informational publications, while BlogPosting more accurately describes a single blog post. Both types can contain author, images, dates, and other similar properties.
If the material is published on a corporate or expert blog as a standalone post, it's usually logical to choose BlogPosting. For other editorial formats, a generic Article can be used if a more specific type doesn't suit the content.
When should you use NewsArticle?
NewsArticle is used for materials that are genuine news or journalistic publications. This type is suitable for online media, editorial news sections, and other pages that cover an event as a stand-alone news story.
Don't use NewsArticle for regular SEO text, instructions, or corporate articles without news context. Selecting this type also doesn't guarantee the publication will appear in Top Stories or Google News.
What fields need to be filled in the Article Schema?
For most publications, it's useful to specify the headline, author, image, datePublished, and, if there are significant updates, dateModified. You can also pass the description, publisher, articleSection, inLanguage, mainEntityOfPage, and other applicable properties.
There's no fixed, universal set of values that must be filled in at all costs. The markup must contain reliable data for the specific page. If the properties can't be supported by the site's content, there's no point in inventing a value just for the sake of a completed form.
Where to insert the finished JSON-LD?
The completed JSON-LD is added to the HTML page within <script type="application/ld+json">. On sites with a CMS, it's best to output the code automatically via a post template so that the data is updated along with the author, image, URL, and dates.
After implementation, you should check the published page, as the theme or SEO module may already be outputting its own markup. This check helps quickly identify duplicates and contradictory Article objects.
How to check Article Schema?
For technical verification, you can use Google Rich Results Test and Schema.org Validator. The former helps you see structured data in the context of Google's supported search capabilities, while the latter checks the overall structure of Schema.org types and properties.
After publishing, you should test the actual URL, not just the individual JSON-LD. For an indexed page, you can also use URL Inspection in Search Console to ensure Google is receiving the latest version of the document.
Does Article Schema help improve Google rankings?
The mere presence of Article Schema does not guarantee a higher page ranking. Structured data helps search engines more accurately determine publication properties, but ranking depends on content, relevance, the technical condition of the site, links, and other signals.
Therefore, the Article microdata generator should be used as part of the technical setup of a page. If the content is blocked from indexing, contains duplicates, or has weak content, adding correct JSON-LD will not solve these problems on its own.
Can Article Schema be used alongside other schema markup?
Multiple Schema.org types can be used on a single page, as long as each object corresponds to real content. For example, an article could simultaneously have an Article, a BreadcrumbList, and Organization data.
However, objects should not contradict each other or duplicate the same entity with different values. After adding several types, it's best to check the final page as a whole to ensure that the relationships between entities are formed correctly.
Related services
Organization Schema Generator
Free Organization Schema Generator: Create JSON-LD markup for your company, add your name, logo, address, contact information, and sameAs, copy the code, and validate it.
BreadcrumbList Schema Generator
Breadcrumb Schema Generator for creating JSON-LD markup for BreadcrumbList. Add names and URLs, get the finished code, and validate it for Google.
Product Schema Generator
Online Product Schema Generator: create JSON-LD microdata for your product with price, availability, brand, rating, and offer information. Copy the code and test it before publishing.
Article Schema is useful when a page actually contains a standalone publication and its properties need to be conveyed to search engines in a structured manner. The choice between Article, BlogPosting, and NewsArticle depends on the content format, and the quality of the markup is determined by the accuracy of the author, dates, images, URLs, and other data.
Use the Article Schema generator, fill in only valid information, validate the resulting JSON-LD, and test the published URL after implementation. For a large site, transfer the verified structure to a CMS template so that the markup is updated with each publication and does not require manual maintenance.
We reply within one business day. No newsletters, no “just a reminder” calls.
He will look at the site himself instead of passing it to a manager.
More on: Article Schema Generator
What is Article Schema?
Article Schema is a structured data type from Schema.org for describing articles and other editorial content. The markup conveys page content in a machine-readable structure, with the title, author, images, publication dates, last updated dates, and related information clearly identified.
The names "article json ld generator", "article markup generator", and "article structured data generator" generally refer to the same class of tools. They help generate Article markup without manually writing JSON-LD. The Article microdata generator reduces technical work, but the resulting code still needs to be validated before deployment.
How does Article Schema relate to Schema.org?
Schema.org contains a common vocabulary of types and properties that websites can use to describe entities in a structured manner. Article is part of this vocabulary and has more specific child types, the most common of which for general websites are BlogPosting and NewsArticle.
Properties like headline, author, image, datePublished, and dateModified provide unambiguous labels for publication data. Search engines can use this information when processing pages. However, Schema.org describes the data structure more broadly than the requirements of a specific search engine.
What is JSON-LD?
JSON-LD is a format for transferring related structured data based on JSON. On a web page, this code is typically placed within the tag, eliminating the need for the developer to add Schema.org properties directly to each piece of visible HTML markup.
This format is convenient for automatic generation, CMS, and server-side rendering. The markup can be created separately, validated, and then output in the article template. JSON-LD must remain accessible to search engines and describe the same information a user receives when viewing the page.
How is Article Schema different from regular HTML markup?
HTML defines the document's structure for the browser and user: headings, paragraphs, links, images, and other page elements. For example, the H1 tag displays the main document heading, and the <img> element displays an image the user sees within an article.
Article Schema adds a machine-readable description of the publication itself. It explicitly links the title to headline, the author to author, and the date to datePublished. Regular HTML and structured data work in parallel, so JSON-LD doesn't replace proper page structure or correct weak content.
Article, BlogPosting, and NewsArticle – What's the Difference?
The three types belong to the same Schema.org family but describe different publication formats. The generic Article is suitable for a wide range of materials, BlogPosting more accurately describes a blog entry, and NewsArticle is intended for news and journalistic content.
It's best to base your choice on the actual purpose of the page, rather than on the keyword or expected SEO impact. If the publication matches a more specific type, using it makes the data clearer and reduces the likelihood of semantic discrepancies between JSON-LD and the visible portion of the document.
| Schema Type | What content is it suitable for? | A typical example | When to choose |
|---|---|---|---|
| Article | Information and editorial materials | Analytical review of the industry | When a more precise type is not required |
| BlogPosting | Blog posts and expert publications | Article on the corporate blog | When the material is a separate blog post |
| NewsArticle | News and journalistic publications | Online publication news | When a page is actually news content |
The selection scheme may look like this:
Publication
│
├── Blog Post ─────────> BlogPosting
│
├── News Article ────> NewsArticle
│
└── Other material ──────> Article
When to use Article?
Article is suitable for publications that are editorial or informational in nature, but not directly related to a blog or news format. This could be an industry review, a comprehensive expert piece, a study, or a publication in the information section of a corporate website.
Using a general type is fine unless a more specific type describes the material more accurately. Don't choose NewsArticle for a regular guide or BlogPosting just because the article is regularly updated. Schema semantics should follow the content of the specific page.
When to use BlogPosting?
BlogPosting is recommended for blog posts where the publication has a separate URL, author, date, and location within the overall structure of the site's content. This format is often used by corporate blogs, educational platforms, SaaS companies, agencies, and expert projects.
If a user is looking for a blog post schema generator, they're usually looking for a ready-made JSON-LD for this specific format. The generator should render the post data without changing its meaning and help maintain a consistent markup structure across different articles in the same section.
When to use NewsArticle?
NewsArticle is intended for news articles and journalistic publications where the publication date and authorship are part of the editorial context. The page must genuinely serve a news function, and the data in the Schema must match the information published to the reader.
NewsArticle markup alone doesn't guarantee inclusion in Google news blocks. Therefore, changing the standard article type for Top Stories is pointless. Correct classification reduces data ambiguity, but search visibility depends on page quality and other signals.
What data can be added to Article JSON-LD?
The set of properties depends on the type of content, the site structure, and the actual information available. For most publications, it's useful to convey the title, author, image, and dates, and, if necessary, supplement the object with a description, language, category, publisher, and a link to the main page.
Google doesn't require a fixed, universal set of mandatory properties for every Article markup. Therefore, it's better to add applicable and reliable data rather than filling in fields pro forma. The Article Schema generator should help the user create a clear structure without fictitious values.
Basic properties of the article
Primary data includes properties that can most often be clearly associated with the visible portion of a publication. They help search engines understand the title of the material, who prepared it, when it was published, and which images are directly related to its content.
When implementing automatically, it's best to retrieve these fields from the CMS so that the values are updated along with the article. Manual JSON-LD requires additional monitoring after each page change, especially if the editor changes the author, image, or the date of the last significant update.
headline
The headline contains the publication's title and should convey it without any artificial additions for SEO purposes. In most cases, the value can be taken from the main title of the material or the corresponding CMS field, as long as it doesn't conflict with what the user sees on the page.
Don't turn the headline into a separate SEO title with additional keywords, cities, and commercial modifiers. If the title of the content changes, the JSON-LD should also be updated, otherwise search engines will receive different versions of the same element.
author
author indicates the publication's author and can reference a Person or Organization entity. For expert content, it's useful to include the specialist's real name and the URL of their page if the site has a full profile with author information.
If the publication was prepared by an editorial team, the structure depends on how the authorship is displayed on the website. Avoid creating a persona that the user never sees. The markup should replicate actual editorial data, not be filled in solely for the sake of completeness in JSON-LD.
image
image links a publication to an image that represents its content. For an article, this typically means a main illustration, photograph, or other graphic used directly in the article and accessible via a stable URL.
The file should not be closed via robots.txt, authorization, or temporary links. When updating the main illustration, it is advisable to simultaneously update the value in the structured data. Using a logo instead of an article image reduces the accuracy of the description of the entity.
datePublished
datePublished contains the original publication date of the material. If an article first appeared on March 10th and was subsequently significantly updated in June, the original date should be retained as the publication date if the site's editorial policy displays it to the user.
For an automated website, it's best to take this value from a constant CMS field that doesn't change during normal editing. This approach prevents situations where each document save accidentally creates a new first publication date.
dateModified
dateModified reflects the date of the last significant content update. It can be changed after adding new data, reworking sections, changing conclusions, or making other edits that actually affect the published material.
Don't update a field after changing a button color, a system template, or correcting a single typo. If the update date is displayed to the user, the JSON-LD value should match it. It's best to use the standard ISO 8601 format for transmitting the date.
Additional properties
Additional properties help to more accurately describe the context of a publication, but their availability depends on the specific page. On one site, articleSection might be useful, on another, inLanguage or publisher, while some data might already be passed through the related entities Organization and WebSite.
Adding every available Schema.org property is unnecessary. The more complex the JSON-LD, the more difficult it is to ensure its consistency with the actual page content. Working markup must remain understandable and predictable through subsequent updates.
description
Description contains a brief description of the article's content. It can be generated from the actual article blurb or a separate CMS field, as long as the text accurately reflects the publication and doesn't create a new meaning not present in the main document.
The description in Schema and the HTML meta description may match, but this is not a technical requirement. Both texts must accurately describe the page. Artificially listing keywords within the property impairs data readability.
articleSection
ArticleSection helps you specify the heading or topic section to which a piece of content belongs. For a blog, this could be SEO, analytics, development, marketing, or another existing site category used in the navigation and structure of posts.
There's no need to create a separate value just for structured data if that category doesn't exist elsewhere. For a large-scale content project, it's convenient to automatically generate articleSection from the article category so that the schema remains consistent across all publications in the section.
inLanguage
inLanguage indicates the language of the content and is especially useful for sites with multiple language versions. The value should correspond to the actual language of the page, not the browser interface language or the visitor's geographic region.
For a multilingual website, each localized publication should receive its own correct language along with its URL and text. This property does not replace hreflang, as hreflang serves a different purpose and associates alternative language versions of a URL.
mainEntityOfPage
mainEntityOfPage indicates the relationship of an Article to the main page where the material is published. This property helps clearly indicate that the article being described is the main entity of a specific document, not a secondary element within another page.
When filling out the form, you must use the correct URL of the publication itself. Do not include the site's main page, blog category, or other content. For the canonical page, the data must remain consistent with the canonical and actual URL indexing.
publisher
Publisher transmits the publication's publisher information. On a corporate website, this is usually the organization that owns the resource, while in online media, it's the editorial staff or company producing the material. The entity can use the name, URL, and available logo.
It's best to link values to the general Organization information already used on the site. If the company name in the header, Organization Schema, and Article publisher differ without reason, such a structure creates unnecessary ambiguity.
keywords and wordCount
Keyword(s) can describe thematic concepts of the material, and wordCount(s) can describe the text's word count. These properties are additional data and should not be used as a way to convey a list of promoted keywords to a search engine.
If the CMS can calculate wordCount automatically, the value can be generated when publishing or updating content. Manual calculations quickly become outdated after editorial edits. Keywords are also best used only if there's a clear data source.
How to add Article Schema to a website?
The implementation method depends on the CMS and project architecture. For a few individual articles, JSON-LD can be added manually, but on a large site, it's safer to automatically generate markup from article fields. This way, author information, URLs, images, and dates are updated along with the publication itself.
Before mass implementation, it's worth testing the template on several typical pages. Also, ensure that the site isn't already displaying Article Schema via an SEO plugin, theme, or other module. Otherwise, the new code may create a second object with inconsistent values.
Inserting JSON-LD into HTML
The completed markup is placed within the tag. The search robot should receive this code along with the page and have access to all URLs specified within the object, including images, the author's profile, and the publication's URL.
Manual insertion is suitable for a small number of pages, but requires monitoring after each change. If the editor updates the author or main illustration but the JSON-LD remains the same, the structured data begins to diverge from the actual page.
Adding via CMS
On a site with a large number of publications, it's best to generate the Article Schema automatically from CMS fields. The title can be taken from the article title, the author from the user profile, the image from the primary media field, and the dates from the publication and update system values.
This approach reduces manual errors and better handles content scaling. When changing a template, the developer only needs to edit one generation mechanism instead of hundreds of pages. Furthermore, each field must be validated to ensure the CMS doesn't display empty properties.
Article Schema on SSR sites
For Next.js, Nuxt, and other SSR solutions, it's convenient to generate JSON-LD simultaneously with the server-side HTML page. The search engine receives structured data immediately upon loading the document, without requiring additional user interaction or complex client-side logic.
In a multilingual project, the generator must take into account the language, URL, and localization data. Russian, Ukrainian, and English versions of the same article may have different headlines, descriptions, and author URLs, so these values cannot be copied between locales without verification.
How to check Article Schema after generation?
You should first check the code itself, and then the entire published page. A single JSON-LD might be syntactically correct, but after implementation, the site might display a second Article, change the URL, or insert data from another template that wasn't visible in the generator.
For a comprehensive check, it's helpful to combine several tools. Google Rich Results Test displays data in the context of supported search features, Schema.org Validator checks the structure against the Schema.org dictionary, and Search Console helps analyze a page already available to Google.
Google Rich Results Test
Google Rich Results Test is suitable for checking structured data used by Google in supported search results formats. You can submit a published URL or code to the tool, which then checks for detected entities, errors, and warnings.
A warning doesn't always mean the page is technically broken, so each message should be read in the context of the specific feature. After implementation, it's best to test the actual URL, as it displays the actual page along with the site's template markup.
Schema.org Validator
Schema.org Validator helps validate an object's structure against the common Schema.org vocabulary. This analysis is useful when you need to see types and properties beyond the limitations of specific Google rich results or when you need to validate a complex object with multiple related entities.
The validator doesn't evaluate the quality of the text itself or verify the author, dates, or publisher. Therefore, the absence of a technical error doesn't necessarily mean the markup is substantively correct. These values must be compared separately with the actual page.
Checking the published page
After deploying the JSON-LD, open the resulting URL and check the original HTML, structured data, and the availability of linked resources. For content already indexed, you can also use URL Inspection in Google Search Console to check whether the current version of the page is accessible to Google.
Checking is especially necessary after changes to the CMS, template, or SEO module. A website update can add a second schema or remove some fields without causing a visible error on the page, so periodic technical monitoring helps identify such issues early.
What pages are suitable for Article Schema?
Article Schema is suitable for pages where the primary entity is truly a standalone publication with a title, content, and editorial context. These typically include blog articles, news stories, research papers, expert reviews, analytical overviews, and educational publications.
Before implementation, it's important to define the type of each URL group to avoid extending Articles to pages related to products, categories, or services. The markup generator is more convenient to use after this classification, since the form itself doesn't determine the document's purpose.
Article markup is most often suitable for the following pages:
- articles from a corporate or expert blog that have a separate author and publication date;
- news materials that are published by the editorial board and relate to current events;
- research, analytical reviews and informative industry publications;
- educational materials, instructions and guides, if the main essence of the page remains an article;
- editorial reviews, where the content is presented as a stand-alone publication, rather than a product card.
For other types of pages, you should first check whether a more suitable Schema.org entity exists. This separation helps avoid a situation where a single markup is mechanically applied to the entire site.
Generally, Article should not be used for the following documents:
- home page, where the main object is the site or organization;
- a blog category or directory containing a list of several materials;
- product cards, for which the main object is Product;
- contact or company information pages;
- commercial landing page service, if it is not an independent editorial publication.
After classification, you can configure automatic Schema output at the template level. Then, the Article Schema generator will be useful for checking the structure, test pages, or projects where automatic microdata has not yet been configured.