GEO INSIGHT
SUMMITFEED 홈페이지 GEO 구조화 전후 리포트: JSON-LD 적용 코드 비교
SUMMITFEED 홈페이지의 JSON-LD 적용 전후 코드를 Git 이력과 현재 운영 코드로 비교하고 Organization·WebSite·WebPage·Service·FAQPage 구조를 설명합니다.
빠른 결론
변경 전 홈페이지는 화면 UI를 렌더링했지만 홈페이지 엔터티를 설명하는 JSON-LD 삽입 코드는 없었습니다.
현재 코드는 Organization, WebSite, WebPage, BreadcrumbList, Service, FAQPage를 절대경로 ID와 실제 화면 데이터로 연결합니다.
전후 비교는 추정이 아니라 Git 커밋의 app/page.tsx와 현재 main 코드를 기준으로 했으며, 캡처에는 공개 가능한 코드만 포함했습니다.
핵심 변화는 스키마 개수를 늘린 것이 아니라 브랜드·사이트·페이지·서비스·FAQ의 관계를 초기 HTML에서 일관되게 전달하도록 바꾼 점입니다.
변경 전
JsonLd, schema.org, application/ld+json 연결 코드 0건
변경 후
홈페이지에 6개 Schema.org 유형을 JSON-LD로 출력
검증 기준
Git 이력의 실제 파일과 현재 운영 main 코드 비교
해석 원칙
사이트 이해 기반을 보강한 것이며 노출·인용 성과 보장은 아님
리포트 범위와 비교 기준
이 리포트는 SUMMITFEED 홈페이지에 GEO 관련 구조화 데이터가 연결되기 전과 현재 운영 코드의 차이를 기록합니다. 비교 대상은 저장소의 app/page.tsx이며, 변경 전 기준은 JSON-LD 도입 직전인 2026년 7월 10일 커밋 e519dc0, 변경 후 기준은 2026년 7월 24일 main 커밋 c2cf075입니다.
확인한 사실과 해석을 구분했습니다. 확인한 사실은 각 시점 파일에 존재하는 import, Schema.org 유형, @id, URL, 렌더링 코드입니다. 검색엔진이나 생성형 AI가 이 구조를 어떤 가중치로 평가하는지는 공개되지 않으므로, 특정 순위나 인용 결과의 직접 원인으로 단정하지 않습니다.
| 구분 | 기준 시점 | 확인 파일 | 확인 방법 |
|---|---|---|---|
| 변경 전 | 2026-07-10 · e519dc0 | app/page.tsx | JsonLd·schema.org·application/ld+json 문자열과 삽입 코드 부재 확인 |
| 변경 후 | 2026-07-24 · c2cf075 | app/page.tsx | 현재 JSON-LD 배열과 JsonLd 컴포넌트 삽입 코드 확인 |
커밋 해시는 재현 가능한 비교 기준이며, 이후 코드가 변경되면 현재 상태와 달라질 수 있습니다.
변경 전: 화면 UI는 있었지만 홈페이지 엔터티 설명은 없었습니다
변경 전 app/page.tsx는 use client로 시작해 화면 상태와 인터랙션을 직접 관리하는 구조였습니다. 화면을 보여주는 기능은 있었지만, 공식 회사·사이트·페이지·서비스·FAQ의 관계를 JSON-LD로 출력하는 연결부는 확인되지 않았습니다.
이 상태를 곧바로 크롤링 불가라고 해석하면 안 됩니다. 일반 HTML 텍스트와 링크는 별도로 수집될 수 있습니다. 다만 페이지에 등장하는 정보가 어떤 조직의 공식 정보이고 어떤 서비스와 연결되는지 기계가 해석할 수 있는 명시적 엔터티 그래프가 없었다는 뜻입니다.
변경 후 1: Organization과 WebSite를 절대경로 ID로 연결했습니다
현재 코드는 https://www.summitfeed.co.kr을 기준으로 organization, website, webpage의 고유 @id를 만듭니다. Organization에는 써밋피드와 SUMMITFEED 표기, 공식 URL, 문의 이메일, 로고 절대경로, 주요 전문 주제를 명시합니다.
WebSite는 publisher를 organizationId로 연결합니다. 같은 회사명이나 URL을 여러 스키마에 반복해 적는 대신 @id를 이용해 하나의 조직 엔터티를 참조하므로, 브랜드와 사이트의 관계를 더 일관되게 표현할 수 있습니다.
변경 후 2: WebPage·Service·FAQPage를 초기 HTML에 삽입합니다
WebPage는 isPartOf로 WebSite를, about으로 Organization을 참조합니다. Service는 GEO 분석 및 실행의 제공 주체를 같은 Organization으로 연결하고, FAQPage는 홈페이지 화면에 표시되는 faqItems에서 질문과 답변을 생성합니다.
JsonLd 컴포넌트는 이 배열을 application/ld+json 스크립트로 출력합니다. 클라이언트 상호작용을 기다린 뒤 만드는 값이 아니라 서버가 반환하는 초기 HTML에서 확인할 수 있도록 구성되어, JavaScript 실행 여부와 별개로 구조화 데이터를 읽을 수 있습니다.
현재 홈페이지에 적용된 6개 스키마와 역할
현재 홈페이지는 Schema.org 유형 6개를 사용합니다. 유형을 많이 넣는 것 자체가 목표는 아닙니다. 화면에 실제로 존재하는 정보만 표현하고, 조직과 웹사이트, 페이지와 서비스의 관계를 같은 @id 체계로 연결하는 것이 핵심입니다.
| Schema.org 유형 | 현재 표현하는 정보 | 연결 관계 |
|---|---|---|
| Organization | 회사명, 영문명, 공식 URL, 이메일, 로고, 전문 주제 | 다른 스키마가 #organization을 참조 |
| WebSite | 공식 웹사이트명, URL, 언어 | publisher가 Organization을 참조 |
| WebPage | 홈페이지 제목, 설명, 언어 | isPartOf는 WebSite, about은 Organization 참조 |
| BreadcrumbList | 현재 페이지의 홈 위치 | 홈 URL을 목록 항목으로 표현 |
| Service | GEO 분석 및 실행 서비스와 제공 지역 | provider가 Organization을 참조 |
| FAQPage | 홈페이지에 표시되는 질문과 답변 | 화면과 동일한 faqItems 데이터 사용 |
구조화 데이터는 반드시 사용자가 실제 화면에서 확인할 수 있는 내용과 일치하도록 유지해야 합니다.
GEO 관점에서 달라진 점
변경 전에는 브랜드명과 서비스 설명이 화면 문맥에만 존재했습니다. 변경 후에는 공식 조직, 사이트, 홈페이지, 서비스가 어떤 관계인지 명시적으로 표현되고, 회사명과 로고 URL도 하나의 기준으로 통일됐습니다.
이 구조는 검색 시스템과 AI 기반 수집 시스템이 페이지의 주체와 주제를 해석하는 데 사용할 수 있는 기반입니다. 그러나 JSON-LD만 추가했다고 콘텐츠의 정확성, 외부 출처, 사이트 평판, 크롤링 허용 상태, 질문 적합성이 자동으로 개선되는 것은 아닙니다.
따라서 GEO 운영에서는 구조화 데이터와 함께 robots.txt, sitemap.xml, canonical, 내부 링크, 화면 본문, 작성 주체, 발행일과 수정일, 외부 출처를 함께 점검해야 합니다. 적용 후에는 실제 검색 결과와 질문별 언급·인용 변화를 별도로 측정해야 합니다.
| 점검 항목 | 코드 적용 | 운영에서 추가 확인할 내용 |
|---|---|---|
| 브랜드 엔터티 | Organization과 공식 URL 연결 | 사이트 전체 회사명·로고·연락처 일치 |
| 콘텐츠 의미 | WebPage·Service·FAQPage 표현 | 화면 본문과 스키마 내용의 일치 |
| 수집 경로 | 초기 HTML에 JSON-LD 출력 | robots.txt·canonical·sitemap·상태 코드 확인 |
| 성과 판단 | 스키마 유효성 검사 | 질문별 노출·언급·인용·추천을 분리 측정 |
공개 전 검증 체크리스트
구조화 데이터는 코드가 존재하는지만 확인해서는 부족합니다. 최종 운영 URL의 초기 HTML, 스키마 값과 화면 내용의 일치, 절대경로 자산 접근성, 중복 엔터티 여부를 함께 확인해야 합니다.
| 확인 항목 | 확인 방법 | 현재 리포트 기준 |
|---|---|---|
| 초기 HTML 포함 | 페이지 소스에서 application/ld+json 확인 | JsonLd 컴포넌트 삽입 코드 확인 |
| 공식 URL | url·@id·logo가 https 절대경로인지 확인 | summitfeed.co.kr 절대경로 사용 |
| 화면과 스키마 일치 | 회사명·서비스·FAQ를 화면과 대조 | FAQ는 동일한 faqItems 데이터 사용 |
| 엔터티 연결 | publisher·about·provider의 @id 확인 | #organization과 #website 참조 |
| 성과 해석 | 구조 적용과 노출 성과를 분리 | 순위·AI 인용 보장 표현 사용 안 함 |
JSON-LD 운영 체크리스트
- 회사명, 영문명, 공식 URL, 이메일과 로고가 사이트 전체에서 일치하는지 확인
- 로고와 canonical을 포함한 URL이 https 절대경로인지 확인
- 구조화 데이터의 서비스와 FAQ가 실제 화면 본문에 존재하는지 확인
- @id를 이용해 Organization, WebSite, WebPage 관계가 끊기지 않는지 확인
- 운영 배포 후 페이지 소스에서 application/ld+json이 초기 HTML에 포함되는지 확인
- JSON-LD 적용을 검색 순위나 AI 인용 보장으로 표현하지 않기
자주 묻는 질문
JSON-LD를 넣으면 AI 검색에 바로 인용되나요?
아닙니다. JSON-LD는 페이지의 주체와 관계를 해석하는 데 도움을 주는 기반입니다. 실제 언급이나 인용은 질문 적합성, 본문 품질, 수집 가능성, 출처 신뢰도, 시점과 플랫폼 등 여러 조건에 따라 달라집니다.
변경 전 홈페이지는 검색엔진이 전혀 읽지 못했나요?
그렇게 단정할 수 없습니다. 일반 HTML 본문과 링크는 수집될 수 있었습니다. 이 리포트에서 확인한 차이는 홈페이지 엔터티를 설명하는 명시적 JSON-LD 연결 코드의 유무입니다.
왜 회사명과 로고 URL을 절대경로로 적나요?
공식 조직과 자산의 위치를 한 주소 체계로 명확히 표현하고, 페이지 위치와 관계없이 같은 엔터티를 참조하기 위해서입니다.
FAQPage는 화면에 없는 질문도 추가해도 되나요?
화면에서 사용자가 확인할 수 있는 실제 질문과 답변을 기준으로 구성하는 것이 안전합니다. SUMMITFEED 홈페이지는 화면과 JSON-LD가 동일한 faqItems 데이터를 사용합니다.
스키마는 많을수록 좋은가요?
아닙니다. 페이지에 실제로 존재하고 설명할 수 있는 정보만 사용해야 합니다. 유형 수보다 엔터티 관계, 값의 정확성, 화면 내용과의 일치가 중요합니다.
결론: 구조화는 GEO 운영의 기반이지 성과 보장 장치가 아닙니다
SUMMITFEED 홈페이지의 가장 큰 변화는 스키마가 0개에서 6개가 됐다는 숫자가 아닙니다. 공식 조직, 웹사이트, 홈페이지, 서비스와 FAQ가 하나의 URL과 @id 체계로 연결되고 초기 HTML에서 읽을 수 있게 된 점입니다.
이 구조는 브랜드와 페이지의 의미를 더 명확히 전달하지만, 그 자체로 검색 순위나 생성형 AI 인용을 보장하지 않습니다. 정확한 본문, 일관된 브랜드 정보, 수집 가능한 기술 구조, 외부 출처와 반복 측정을 함께 관리해야 합니다.
써밋피드(SUMMITFEED)는 코드 적용 여부에서 끝내지 않고 화면 정보와 스키마의 일치, 수집 경로, 질문별 노출 변화를 함께 점검하는 방식으로 GEO 구조를 운영합니다.