How to Apply JSON-LD to a Website — Actual Code Connecting Organization, Website, and Service via @id

Before application, the homepage rendered the screen UI, but there was no JSON-LD declaring entities based on app/page.tsx.

Currently, the Korean and English homepages and article pages each output a single @graph within a single script. There are 7 top-level nodes, and 0 unreferenced orphan nodes.

FAQs are created by mapping the screen rendering array exactly. 9 Korean items, 8 English items, and 5 Article items match exactly in the screen and schema.

The biggest change is not the number of types. It is the removal of orphan nodes from the first version and the work of identifying five instances in the English version where issues fixed in the Korean version remained.

JSON-LD (JavaScript Object Notation for Linked Data) is a format that inserts structured data into HTML using <script type="application/ld+json"> blocks. It uses the Schema.org vocabulary. There are three types of structured data formats, but in practice, they are effectively consolidated into a single type.

JSON-LD is separated from screen markup. Data does not break even if the design is changed. Google also recommends this format.

The reason for applying it starting from the homepage is that it serves as a reference point. The Organization entity is the root that the entire site references. If you declare an Organization on the homepage and assign an @id, subpages only need to point to that @id instead of repeatedly writing company information. Conversely, if you modify the subpages first, the same company will be split into multiple entities.

The background of the GEO perspective is summarized separately in the What is GEO Guide.

The baseline before the change was commit e519dc0 on 2026-07-10, just before the introduction of JSON-LD. At that time, app/page.tsx started with use client and directly managed screen states and interactions. The search results for the strings JsonLd, schema.org, and application/ld+json in this file were 0.

I will clarify the scope of verification. The results above are based on a single file, app/page.tsx. In Next.js App Router, JSON-LD is injected into layout.tsx and shared components as well. To use this as a page-level conclusion, you need to broaden the search scope.

Do not interpret this state as uncrawlable. The HTML body is collected. The problem is not collection, but interpretation.

Regardless of how many times a company name appears on a page, there was no basis to determine whether it was the official organizational name or a word within the body text. The same applies to whether a number is a representative number, or whether the service description refers to this company or another. Humans understand through context. Machines need a declaration to understand.

Commit hashes are an internal reproduction standard. Since the repository is private, it cannot be directly viewed from the outside. If public verification is required, you can compare it with the rendered HTML preserved at that point in time.

This is the first node created. All other nodes reference this.

{ 
"@type": "Organization", 
"@id": "https://www.summitfeed.co.kr/#organization", 
"name": "SUMMITFEED", 
"alternateName": ["SUMMITFEED", "SUMMITFEED"], 
"url": "https://www.summitfeed.co.kr/", 
"logo": { 
"@type": "ImageObject", 
"@id": "https://www.summitfeed.co.kr/#logo", 
"url": "https://www.summitfeed.co.kr/images/brands/summitfeed-logo.png", 
"width": 1481, 
"height": 470, 
"caption": "SUMMITFEED" 
},
"identifier": {

"@type": "PropertyValue",

"name": "Business Registration Number",

"value": "884-73-00630"

},

"taxID": "884-73-00630",

"sameAs": ["https://summitfeed.tistory.com/"],

"knowsAbout": [

"Generative Engine Optimization",

"AI Search Optimization",

"Structured Data",

"Schema.org"

]

}

There is a reason for every attribute.

`@id` — This is the unique address of this organization. It uses the format Homepage URL + #organization. Instead of other nodes repeating the company information, they point to this value.

`alternateName` — Enter both Korean and English. Whether searched for "SUMMITFEED" or "SUMMITFEED", it leads to the same entity.

`logo` — A string URL is valid, but using ImageObject passes the dimensions and caption. Google requires the logo to be at least 112×112px.

`identifier` and `taxID` — The business registration number is entered in two forms. identifier is labeled with a human-readable label like name: "Business Registration Number", while taxID is a Schema.org standard attribute, ensuring machine readability. It is worth including both as they are unique values ​​that distinguish entities with the same name.

`sameAs` — Links to an externally public profile. Without this attribute, all organization information remains as self-declarations.

There is a point here where it is easy to make a mistake. You must only enter organizational accounts.** If you include the representative's personal blog in the Organization field, you are essentially claiming "this organization = personal profile." When we first generated the list, we almost overlooked the fact that Brunch and Medium are personal accounts.

`knowsAbout` — Enter the professional topic in both Korean and English. Topics are detected even in English queries.

Sites and pages are placed on top of the Organization.

{ 
"@type": "WebSite", 
"@id": "https://www.summitfeed.co.kr/#website", 
"url": "https://www.summitfeed.co.kr/", 
"publisher": { "@id": "https://www.summitfeed.co.kr/#organization" }, 
"inLanguage": "ko-KR"
}

{ 
"@type": "WebPage", 
"@id": "https://www.summitfeed.co.kr/#webpage", 
"url": "https://www.summitfeed.co.kr/", 
"isPartOf": { "@id": "https://www.summitfeed.co.kr/#website" }, 
"about": { "@id": "https://www.summitfeed.co.kr/#organization" },

"breadcrumb": { "@id": "https://www.summitfeed.co.kr/#breadcrumb" },

"mainEntity": { "@id": "https://www.summitfeed.co.kr/#faq" },

"primaryImageOfPage": { "@id": "https://www.summitfeed.co.kr/#logo" },

"dateModified": "2026-08-17",

"inLanguage": "ko-KR"

}

Relationships are read like this.

URL notation must be standardized character by character. https://example.com and https://example.com/ look the same to the human eye, but they are different values ​​when comparing strings. We have even matched the trailing slashes of self-referencing URLs 5 — canonical, Organization.url, WebSite.url, WebPage.url, BreadcrumbList.item —.

I would also like to point out dateModified. If you store this value as a string, it will inevitably conflict with the update date displayed on the screen. Group it into a single constant so that the schema and footer see the same value. This will be discussed again later.

{

"@type": "Service",

"@id": "https://www.summitfeed.co.kr/#service-geo",

"name": "GEO Analysis and Execution",

"serviceType": "Generative Engine Optimization",

"provider": { "@id": "https://www.summitfeed.co.kr/#organization" },

"areaServed": { "@type": "Country", "name": "South Korea" }

}

In serviceType, enter the official English name. For areaServed, the Country object is clearer than a string like "KR".

FAQPage has only one rule. Create this from the screen rendering array.

{

"@type": "FAQPage",

"@id": "https://www.summitfeed.co.kr/#faq",

isPartOf: { "@id": "https://www.summitfeed.co.kr/#webpage" },

mainEntity: faqItems.map((item) => ({

"@type": "Question",

name: item.question,

acceptedAnswer: { "@type": "Answer", text: item.answer },

})),
}

faqItems is the very array that the screen FAQ section renders. The key is not to match the text, but to create a structure that cannot be misaligned.

Initially, we also wrote the questions and answers separately in the schema. However, while modifying the screen text, only the schema was updated, and three places became misaligned. One of them was a situation where a question existed only in the schema but was not on the screen at all. After switching to a map method for arrays, this type of error became structurally impossible.

FAQ Rich Results were discontinued in 2026 5

Google removed FAQ Rich Results from search results as of 7 in 2026 5. In 6, the FAQ search impression type, Rich Results reports, and Rich Results test support in Search Console were removed, and Search Console API support will be removed in 8.

However, the reason FAQPage is maintained is not because of Rich Results. FAQPage is still a valid Schema.org type and serves to group on-screen Q&A and machine-readable data from the same source. If you included it solely for the sake of Rich Results impressions, now is the time to reconsider.

The Organization node alone does not leave a record of "who wrote it." We created Person as a separate node and connected it via worksFor.

{

"@type": "Person",

"@id": "https://www.summitfeed.co.kr/#founder",

"name": "Lee Seung-chan",

"jobTitle": "CEO",

"url": "https://www.summitfeed.co.kr/about",

"worksFor": { "@id": "https://www.summitfeed.co.kr/#organization" },

"sameAs": [

"https://brunch.co.kr/@609024f8b3744e2",

"https://medium.com/@dltmdcks623100"

]

}

On the Organization side, this is referred to as founder It points to the node. It is bidirectional.

Dividing it this way prevents personal and organizational channels from mixing. Brunch and Medium are representative personal accounts, so they go into Person.sameAs, while Tistory is an organizational account, so it goes into Organization.sameAs.

There is a method to change the personal account to the company name, but I do not recommend it. In terms of "who wrote it," a person's name is a stronger signal than a company name. There is nothing to be gained by deleting the author entity.

This is the story of what actually happened.

The first version was a method of listing 6 types in an array. @context was written repeatedly for each object, and @id was attached to only three of them.

Without @id, it cannot be referenced. Service pointed to Organization as provider, but conversely, Service could not be pointed to anywhere. FAQPage was completely floating as it had no relationship attributes.

It is not a syntax error. It also passes the Rich Result test. However, it was not in a state where it could be said to "convey the relationship between Brand, Site, Page, Service, and FAQ."

The fix consisted of three steps.

1. Convert the array to a single @context + @graph

1. Assign @id to the three nodes

1. References from WebPage to breadcrumb and mainEntity, and from Organization to Service to makesOffer

{

"@context": "https://schema.org",

"@graph": [ /* 7 nodes */ ]

}

By using @graph, you only need to write @context once, and references between nodes are visible at a glance. As a result, the number of types increased from 6 to 7, but the actual change is that orphan nodes increased from 3 to 0.

This section is the most practical part of this article.

After fixing the Korean page and checking the English page, the same problem remained five times. Every time I fixed one, I thought, "I already fixed this earlier."

4 was particularly noticeable. The Korean footer was 2026-08-17, while the English footer was July 24, 2026. The same information on the same site was spread out by more than 3 weeks depending on the language.

The cause is simple. It is because I made the corrections while looking at the Korean screen. The English pages exist in a separate file with separate text, but I did not open that page when correcting the Korean version.

What to Separate and What to Share by Language

This is the most confusing point in multilingual JSON-LDs. The criterion is "is there only one entity?"

Nodes sharing @id must have the same set of attributes. If the same #service-geo exists but areaServed is present only in Korean, it is effectively describing the same entity twice differently.

One more thing here. If the value of a shared node is in Korean, it will appear in Korean on the English page as well. This is the case with Person's name. Since there is only one entity, the value should not be changed; instead, it is more appropriate to add the English notation using alternateName.

There is a difference between code existing and what the search system reads.

If you inject a JSON-LD inside useEffect, it enters the browser DOM but is not in the initial HTML returned by the server. Checking with `document.querySelectorAll` in the browser console does not prove this either. This is because it views the DOM after hydration is complete.

Verification is done using curl.

curl -s https://www.summitfeed.co.kr/ | grep -o '"@type":"[^"]*"' | sort | uniq -c

This is the current result of running the Korean homepage.

There are 1 script blocks and 7 top-level nodes. The fact that Question and Answer each have 9 instances means they exactly match the 9 items in the FAQ on the screen. ContactPoint, ImageObject, PropertyValue, and Country are child objects contained within the parent nodes.

This is the result of verifying the three pages in the same way.

The validation tools use two together. Rich Result Test checks for Google Rich Result qualifications, while Schema.org Validator checks the JSON-LD syntax itself. The latter catches syntax errors when types not supported by Google are used. Running only one will miss them.

1. Adding content that is not visible on the screen only to the schema

Google’s general guidelines for structured data explicitly prohibit the markup of content that is not visible to the reader. This provision remains valid even now that the FAQ Rich results have ended, and violations are subject to manual action. Adding star ratings or prices that are not visible on the screen falls into the same category.

2. Repeating the same information across schemas without @id

If you write the company name, URL, and logo in Organization, Website, and Article respectively, the same company is split into multiple entities. Please assign an @id and refer to them.

3. Relative URL paths

If you write it like /images/logo.png, the interpretation varies depending on the page location. url, @id, and logo must all be https absolute paths.

4. JSON-LD injection within useEffect

Client Values ​​generated after execution are not present in the initial HTML. Please configure them to be output in the server rendering path.

5. Embedding Dates and URLs as Strings

If you write dateModified as a string, it will inevitably be out of sync with the screen update date. The same applies to @id.

We belatedly discovered that @id was embedded as a string in five places in the English file. The value itself was correct, but if the path changes, only that location remains. It takes 5 minutes to enclose it as a constant.

6. Cases where array types are missed when checking with grep

The pattern "@type":"[^"]*" cannot capture arrays like "@type":["Article","TechArticle"]. It does not match because the part after the colon is [. If you think a node is missing and insert it again, it results in a duplicate.

Please check the array type separately.

curl -s <URL> | grep -o '"@type":\[[^]]*\]'

7. Fixing Only One Language on a Multilingual Site

The entire previous section is about this. If you have fixed the Korean version, please check the English version on the same day. If the files are separated by language, one side will always remain at the end.

This is a table for overview purposes. Descriptions of each item are in the previous section.

The goal is not to increase the number of types. The standard is to display only the information currently on the screen and to eliminate duplicate declarations by cross-referencing with @id.

• Do the company name, English name, official URL, email, and logo match across the entire site?

• Are the self-referencing URLs identical strings, including the trailing slash and including the canonical?

• Do the schema's services and FAQs exist within the actual screen content?

• Do all nodes have @id, and are there no orphan nodes that are not referenced?

• Do the dates and @id reference constants, or are they not embedded as strings?

• If it is a multilingual site, have the above items been verified for each language?

• After deployment, does application/ld+json appear in the initial HTML using curl?

• Did it pass both the Rich Result test and the Schema.org Validator?

The third-to-last item is the part we missed the most.

A broader range of checks is summarized in AI Search Visibility Website Audit 25 Checklist.