구조화 데이터 —
화면의 사실과 기계가 읽는 사실을 하나로

A 보장되지 않습니다. 구조화 데이터는 노출을 만들어 내는 장치가 아니라 이미 있는 사실을 기계가 오해 없이 읽도록 돕는 보조 수단이며, 구글도 공식 문서에서 필수가 아닌 보조 수단으로 설명합니다. 값이 정확하면 회사명·연락처·서비스 범위 같은 사실이 잘못 전달될 가능성이 줄어드는 것이고, 인용 자체는 답이 될 문서가 있느냐에 더 크게 좌우됩니다.

A 조직 스키마가 먼저입니다. 전 페이지 공통으로 한 번만 정의하고 나머지 스키마가 그 식별자를 참조하는 구조라, 여기가 어긋나면 뒤에 넣는 것이 전부 흔들리기 때문입니다(오프라인 사업장이 있으면 ProfessionalService 같은 LocalBusiness 계열을 씁니다). 그다음이 페이지 위치를 알려주는 BreadcrumbList, 질문과 답이 짝지어진 FAQPage 순입니다. 그 뒤로는 그 페이지가 실제로 담고 있는 사실의 형태에 맞는 타입만 골라 넣고, 넣지 않기로 한 타입과 그 이유도 매핑표에 함께 남깁니다.

A 접근 권한에 따라 두 가지로 진행합니다. 관리자 화면이나 코드에 접근할 수 있으면 나비랑이 직접 넣고 검증까지 마칩니다. 접근이 막혀 있으면 페이지별로 넣을 JSON-LD 전문과 삽입 위치, 확인 방법을 문서로 정리해 제작사에 그대로 전달할 수 있게 드리고, 적용된 뒤 검증은 저희가 합니다. 임대형 빌더는 머리말·꼬리말에 스크립트를 넣을 수 있는지에 따라 갈리므로 현황 점검 단계에서 먼저 확인합니다.

A 목적이 바뀌었을 뿐 이유는 남아 있습니다. 구글은 2026년 5월부로 FAQ 리치 결과 표시를 끝냈고 관련 문서도 내렸습니다. 다만 FAQPage는 질문과 답이 짝지어진 데이터라 답변엔진이 그대로 인용하기 좋은 형태이며, 나비랑은 검색 결과 장식이 아니라 그 목적으로 넣습니다. 물론 화면에 실제로 보이는 FAQ여야 합니다.

A 화면에 실제로 표시되는 리뷰가 있을 때만 넣습니다. 사이트에 없는 별점을 스키마로만 선언하면 정책 위반이고, 자기 서비스를 자기가 평가한 리뷰는 구글이 리치 결과로 다루지 않습니다. 요청을 받아도 이 선은 유지하고, 대신 화면에 근거가 남아 있는 사실 중에서 선언할 수 있는 항목이 무엇인지 함께 찾습니다.

A 선택 항목으로 만듭니다. llms.txt는 공식 표준이 아니고, 구글은 검색에서 이를 사용하지 않는다고 명시했으며 다른 주요 엔진의 공식 확인도 없습니다. 다만 파일 하나를 두는 비용이 거의 없고, 쓰는 과정에서 한 문장 정의와 핵심 페이지 목록이 정리되는 효과가 있어 필요한 경우에만 함께 진행합니다. 자동 생성되지 않으므로 갱신 대상 목록에 함께 넣어 관리합니다.

A 먼저 검증부터 합니다. 실무에서 자주 나오는 것은 화면 값과 어긋난 항목, 끝 슬래시가 섞인 URL, 같은 조직이 페이지마다 다르게 선언된 경우입니다. 점검 결과 문제가 없으면 그대로 두고, 잘못된 선언은 고치거나 지우는 것까지가 작업 범위입니다.