How to Generate and Validate Structured Data Before Publishing
A practical workflow for generating JSON-LD, checking Schema.org markup and Google rich-result eligibility, and testing the published page.

A schema generator can save you from typing JSON-LD by hand. It cannot decide whether the information you enter describes the page, or whether Google will show a rich result. Treat its output as a draft: choose the type, inspect the fields and markup, then test the page where you publish it.
Choose the type from the page, not the menu
Start with the page you intend to mark up. An article at /guides/schema-validation/ is a plausible candidate for Article; a product page at /products/widget/ is a plausible candidate for Product. Those are examples of a content match, not a declaration that either page qualifies for a Google search enhancement.
Select a type and enter information that accurately describes that page or the item on it. A generator may offer several choices—one generator lists Article, Product, FAQ, BreadcrumbList and LocalBusiness—but a menu option is not evidence that the selected type fits your URL. Check the fields against what a visitor can actually find on the page. If the page is a guide about a widget, for example, do not choose Product merely because the guide mentions one.
Review the properties the selected type calls for rather than assuming the form has captured everything. The generator workflow described by Cloud SEO Tool explicitly pairs matching the type to the content with including required properties. If you cannot supply an accurate value, reconsider the type or the markup; filling a field with a convenient guess only makes the output harder to trust.
Put the JSON-LD on the relevant page
In a generator, select the type, complete the fields, generate or copy the JSON-LD, and add it to the HTML of the page it describes. Some forms update the output while you type; Backlinko’s generator describes that live-update behavior. Either way, read the finished output before publishing. In particular, compare its type, URL and descriptive values with the page you meant to edit.
For an illustrative article page, the placement might look like this. The values are examples, not a complete property checklist:
<head>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to Validate Structured Data",
"url": "https://example.com/guides/schema-validation/"
}
</script>
</head>
The JSON-LD belongs in the relevant page’s HTML; it can be placed in the <head> or <body>, as SEO Image’s generator instructions describe. If you are working through a CMS template or a shared component, check which pages receive that component. Markup intended for the article URL should not silently become the description of every page that uses the template.
Run two checks that answer different questions
Use the Schema.org Markup Validator to check Schema.org-based structured data embedded in the page. Its scope is broad: Google describes it as validation without Google feature-specific warnings. A pass there does not establish eligibility for a Google rich result.
Then use Google’s Rich Results Test to see which Google rich results may be generated for the page. Look for the result type you intended and address any blocking issues the test reports. If the tool offers a preview, inspect it as a possible presentation—not a picture of an actual search result. These checks complement each other: one examines broader Schema.org markup, while the other asks a Google-specific search-appearance question.
A generator producing syntactically tidy JSON-LD is not the end of either check. For example, a value can be formatted correctly while describing the wrong URL. Validation findings tell you what the tools detected; you still need to compare that output with the page.
Test the published URL, then inspect the match
After publishing, enter the deployed URL into the tests rather than relying only on markup copied from a form. Confirm that the intended type is detected on that URL and compare the detected values with the visible page content. If the tool does not detect the markup you expected, inspect the HTML delivered for that URL and compare it with the page after JavaScript runs, then inspect the page or template where you inserted the code. If it detects the markup but reports a problem, check the reported property, its value and the selected type before changing unrelated fields. Correct the page or markup and retest the published URL.
Keep the conclusions narrow. Accurate fields establish a content match. Schema.org validation establishes a broader markup check. Detection without blocking issues in the Rich Results Test supports potential eligibility for the tested Google result type. Detection on the published URL establishes that the deployed page exposes the markup to the test. None of those observations, including a preview, demonstrates that Google has indexed the page or will display a rich result.

