Create JSON-LD Structured Data
To create JSON-LD structured data, start with facts already visible on the page and choose a type that describes them. A generator can organise those facts into a useful script block. It cannot turn unsupported claims into verified business information or certify a page for every search feature.
This guide covers a basic Organization example, then explains how the same preparation changes for an article, product or breadcrumb trail. It is written for website owners and developers who want to understand the output before installing it. You will keep the page content, the chosen schema type and the generated fields aligned.
Begin with one page rather than marking up an entire site at once. Write down the organisation name, URL and other facts you intend to include. Confirm that the page actually supports them. Keep optional fields blank when you do not have reliable information. A small, accurate implementation is easier to review than a long script containing guessed ratings, placeholder prices or an address copied from an unrelated example.
What Is JSON-LD Structured Data?
JSON-LD expresses linked data using JSON syntax. On a website, it can appear in a script element whose type is application/ld+json. Properties such as @context and @type establish the vocabulary and the kind of thing described. Other fields provide the relevant facts.
The SEO Solve generator supports five basic outputs: Organization, LocalBusiness, Article, Product and BreadcrumbList. Each has a different purpose. An Article uses a headline and author, while a Product can include an offer. A BreadcrumbList describes an ordered path rather than an organisation profile.
Google introduces structured data as a way to provide information about page content. Schema.org's documentation describes the broader vocabulary. A vocabulary-valid statement and eligibility for a specific search presentation are related but separate questions.
Why Accurate Schema Inputs Matter
Generated markup is only as reliable as the information you supply. A syntactically valid script can still describe the wrong business, an outdated price or an article author who did not write the page. Local validation cannot establish those facts for you.
Decide where each value comes from. An organisation name might come from the site's approved business details. An article date should come from the actual publication record. Product availability should reflect the displayed offer rather than a convenient default chosen to complete a form.
This preparation also makes maintenance easier. If someone later changes the page's visible offer, they need to know which structured fields depend on it. Keep the fact source and the owner of that information in a simple implementation note.
How to Create JSON-LD Structured Data
Select the type that fits the page. Enter a name or headline and a full HTTP or HTTPS URL. Complete only the additional fields shown for that type. The generator serializes the values as JSON and escapes the less-than character so user text cannot close the generated script element early.
For Organization, review the name, URL, optional description and logo. For LocalBusiness, review the address fields and country code too. An article needs an author and publication date in this basic form. A product requires an explicit price and currency, plus its chosen availability value.
For BreadcrumbList, enter one name and URL per row. The generator assigns positions in that order. Put the hierarchy in the order a reader would follow it, starting with the broader location and ending with the more specific page. Do not use breadcrumb rows as an unrelated list of promotional links.
Copy the output into the appropriate page template and inspect the rendered page afterwards. A CMS or plugin may already add structured data, so check for overlapping or conflicting output. Validate against the requirements for your intended use and confirm the values again after publication. The generator provides a starting point, not a full schema audit.
Examples
A basic fictional organisation might use the name Example Studio and the URL https://example.com/. Its JSON-LD can be small:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Studio",
"url": "https://example.com/"
}
This example makes no claim about reviews, awards or opening hours. Adding more properties is useful only when the information is accurate, relevant and supported by the page and vocabulary.
| Selected type | Key example input | Review before use |
|---|---|---|
| Organization | Name and website URL | Correct entity and destination |
| Article | Headline, author, date | Match the published article |
| Product | Price 299.00, currency ZAR | Match the visible offer |
| BreadcrumbList | Home, then Tools | Correct order and URLs |
For a two-item breadcrumb, the positions are one and two. Reversing the input rows reverses that hierarchy. For a product, 299.00 is a supplied offer price, not a calculated total or tax assessment. These small distinctions help you understand what the generator emits instead of treating its output as an opaque block to paste anywhere.
Common Mistakes
Do not invent a rating because a schema example contains one. A sample field is not permission to claim evidence you do not have. The same principle applies to addresses, authors, offers and credentials. Remove unsupported properties rather than filling them with plausible-looking placeholders.
Avoid installing several competing implementations without checking their output. A theme, SEO plugin and manual script can all describe the same page differently. Inspect the rendered result and decide which system owns the relevant fields. That ownership matters when content changes later.
Another mistake is equating successful JSON parsing with complete schema validation. JSON syntax checks punctuation and structure. It does not know whether your chosen type supports the intended meaning or whether a search engine requires more properties for a particular feature. Review each layer separately and record unresolved requirements.
Frequently Asked Questions
Does generated JSON-LD guarantee a rich result?
No. Search engines apply their own requirements and decide whether to show enhanced results. The generator produces basic markup from your input. Check the relevant feature documentation and the rendered page, and avoid treating a completed form as a promise of search appearance.
Should every page use Product markup?
No. Choose a type that describes the actual page content. A general service description, an article and an individual product offer have different purposes. Do not select a type simply because its example output looks more prominent in a search result.
Why does the output contain escaped characters?
JSON serialization protects characters needed for valid syntax. The generator also escapes less-than signs to keep text from prematurely ending the HTML script block. These escapes represent the supplied text; they are not evidence that the tool changed the business facts you entered.
Can I leave optional fields blank?
Yes. Supply accurate fields that are useful for the selected type. Some search features may require additional properties beyond this basic generator, so check those requirements separately. A blank optional form field is preferable to inventing a value that the page cannot support.
What should I check after publishing?
Inspect the rendered script, confirm that its values match visible content and check for duplicate or conflicting implementations. Then use the relevant validation process for your intended schema use. Repeat the review when details such as an offer, author or organisation address change.
Related Tools
- Structured Data Generator: create basic JSON-LD for the five supported types from verified inputs.
- Heading Structure Checker: review the visible document organisation that surrounds the marked-up content.
- Search Snippet Preview: draft consistent page metadata while keeping search display expectations separate from schema generation.
Conclusion
Choose a type from the page's actual purpose, supply traceable facts and inspect the generated fields before installation. Keep syntax, vocabulary use and search-feature eligibility as separate review steps. After publishing, verify the rendered output and assign responsibility for future updates. Structured data is easier to maintain when every included value has a clear source and an understandable reason to be there.