GEO INSIGHT
How to Implement JSON-LD on a Website: A Before-and-After Production Code Review
This explains how to apply JSON-LD to a website using actual production code. It covers 7 types of code including Organization, Person, Website, WebPage, BreadcrumbList, Service, and FAQPage, as well as @id connections, pitfalls of multilingual sites, and initial HTML validation.
Quick answer
Prior to the change, the homepage rendered the screen UI, but there was no JSON-LD insertion code describing the homepage entities.
The current code connects Organization, Person, WebSite, WebPage, BreadcrumbList, Service, and FAQPage using a single @graph and absolute path ID.
The before-and-after comparison was based on the app/page.tsx from the Git commit and the current main code, rather than on estimation, and the capture includes only publicly available code.
The key change is that instead of the number of types, the relationships between Brand, Representative, Site, Page, Service, and FAQ were changed from the initial HTML to convey them as a single graph.
Before Change
0 instances of JsonLd, schema.org, and application/ld+json connection code
After Change
Outputting 7 parent nodes connected via a single @graph on the homepage
Verification Criteria
Comparison of actual files in Git history with the current operational main code
Interpretation Principles
Exposure, citations, and recommendations record the question, platform, and timeframe, and are measured repeatedly using the same criteria.
Quick Conclusion
What Is JSON-LD, and Why Start with the Homepage?
Before Implementation: What Was Missing from the Website?
How the Organization Schema Was Built
How to Connect WebSite and WebPage Nodes with @id
When to Use Service and FAQPage
Why the Author Uses a Separate Person Node
The First Version's Problem: Three Orphaned Nodes
Five Common Failure Points on Multilingual Sites
How to Verify JSON-LD in the Initial HTML
Seven Common JSON-LD Mistakes
Seven Schema Types Currently in Production
Pre-Release Checklist
JSON-LD Operation Checklist
- ✓ Verify that the company name, English name, official URL, email, and logo are consistent across the entire site
- ✓ Verify that the URL including the logo and canonical is an absolute HTTPS path
- ✓ Verify that the structured data services and FAQs exist in the actual screen body
- ✓ Verify that the relationships between Organization, Person, WebSite, WebPage, BreadcrumbList, Service, and FAQPage are not broken using @id
- ✓ Verify that application/ld+json is included in the initial HTML of the page source after operational deployment
- ✓ Record the JSON-LD application scope and verification results separately
Frequently asked questions
Where should JSON-LD be placed?
It can be in `<head>` or `<body>`. What is more important than the location is **whether it is included in the initial HTML returned by the server**. If it is injected after client execution, it will not be read regardless of the location.
Is it better to have more schemas?
No. We only use information that is actually on the page and can be explained. In our case, eliminating orphan nodes was a much bigger change than increasing the number of types. Relationships, accuracy of values, and consistency with the screen content are more important than the number of types.
For multilingual sites, should `@id` be separated by language?
Nodes with a single entity are shared, while page-level nodes are separated. Organization, Person, and Service are shared, while WebSite, WebPage, BreadcrumbList, and FAQPage are separated by language. Shared nodes must also have the same set of attributes.
Is the FAQ schema no longer necessary?
Google Search FAQ Rich Results were discontinued as of 2026 5 7, and Search Console reporting items are being phased out. However, FAQPage remains a valid type, and the value of the on-screen Q&A content remains unchanged. If the goal was rich results, a review is required; if the goal was consistency between the screen and structured data, you should keep it.
I passed the rich result test, but it doesn't appear in search results.
Passing the test only verifies syntax and qualifications. Actual display is a separate matter, and there are many types that do not provide rich results in the first place. Organization, Website, and Service are examples of this. These types do not create changes to the search screen.
Is `@id` absolutely necessary?
It is valid even without it. However, nodes without `@id` cannot be referenced. Please add it if there are two or more nodes on a single page.
Will including JSON-LD lead to citation in AI search?
**JSON-LD is a condition for citation, not the cause.** Without structure, there is insufficient basis for interpretation, and having structure does not automatically lead to citation. Actual mentions and citations depend on question relevance, content quality, collectibility, source reliability, timing, and platform. We [operate] by establishing the structure first and then repeatedly measuring citations per question (/geo-partner).
Did search engines not read the homepage at all before the application?
They did read it. However, reading is different from understanding. The HTML body and links were collected, but there was no declaration to determine which organization's official information that information was.
Conclusion
Continue reading
Sources and references
This article was written by directly comparing the actual operational code and Git history of the SUMMITFEED website. Search results and Generative AI responses vary depending on the platform, question, time, and user conditions.