구조화 데이터는 페이지의 제목, 작성 주체, 조직과 같은 정보를 정해진 형식으로 설명하는 코드입니다. 검색엔진이 콘텐츠를 이해하도록 돕지만, 코드를 넣었다고 검색 순위나 AI 답변의 소개가 보장되지는 않습니다. 화면에 있는 정확한 정보를 일관되게 표현하는 것이 출발점입니다.
페이지의 역할에 맞는 정보부터 고릅니다
조직 소개에는 조직 정보, 칼럼에는 글 정보, 여러 단계로 나뉜 페이지에는 탐색 경로를 설명할 수 있습니다. Google은 구조화 데이터의 용도와 지원 형식을 안내하며 일반적으로 JSON-LD를 권장합니다. 필요한 타입과 속성은 현재 기능별 문서를 확인합니다. Google 검색 센터 — 구조화 데이터 소개.
전문직 사이트라고 모든 페이지에 모든 타입을 넣을 필요는 없습니다. 서비스 소개인지 실제 칼럼인지 먼저 구분하고, 그 페이지에서 확인할 수 있는 정보를 중심으로 선택합니다. 출처가 없는 자격이나 운영하지 않는 지점을 덧붙이지 않습니다.
보이는 내용과 코드의 내용을 맞춥니다
본문의 제목·작성 주체·날짜를 바꾸면 코드에도 같은 변경을 반영합니다. 사용자에게 보이지 않는 후기나 질문을 코드에만 추가하지 않습니다. Google은 화면에 드러나지 않거나 본문을 제대로 대표하지 않는 정보를 문제로 안내합니다. Google 검색 센터 — 구조화 데이터 일반 가이드라인.
업무 담당자는 실제 정보의 정확성을, 제작 담당자는 코드가 그 정보를 올바르게 표현하는지를 확인합니다. 이름이나 날짜 하나를 여러 곳에서 관리하면 불일치가 생기기 쉬우므로 가능한 한 같은 원본 데이터에서 생성하는 방식으로 설계합니다.
문법 검사와 검색 기능 검사를 나눕니다
먼저 JSON 문법이 맞는지 확인합니다. 따옴표나 쉼표 하나가 잘못되어도 데이터를 해석하지 못할 수 있습니다. 그다음 필요한 속성이 있는지와 URL이 실제 페이지를 가리키는지 점검합니다. 문법이 맞다는 사실만으로 내용까지 정확한 것은 아닙니다.
Google 리치 결과 테스트는 Google이 지원하는 검색 기능을 검사하는 도구입니다. 모든 schema.org 타입이 같은 방식으로 표시되는 것은 아니므로 검사 대상도 확인합니다. 검수 결과에는 사용한 도구, 대상 URL, 오류와 수정 내역을 남깁니다.
리치 결과와 AI 인용은 다른 결과입니다
구조화 데이터를 올바르게 작성해도 리치 결과 표시가 보장되지 않는다고 Google은 설명합니다. 테스트 통과 화면을 검색 결과의 노출 증명으로 제시하지 않습니다. Google 검색 센터 — 구조화 데이터 일반 가이드라인.
FAQ가 있다면 고객에게 실제로 필요한 질문과 답을 먼저 작성합니다. FAQ 코드를 넣었다는 이유로 AI가 반드시 인용한다고 설명하지 않습니다. AI 인용을 확인하려면 해당 검색 화면의 답변과 출처를 별도로 관찰해야 합니다.
홈페이지 운영표에 함께 넣습니다
검수표에는 페이지 주소, 페이지 유형, 코드 생성 위치, 화면과 다른 정보, 수정 담당자와 재확인 날짜를 둡니다. 개편이나 글 갱신 시 본문만 바꾸고 코드가 남는 일을 막기 위한 운영 장치입니다. 삭제한 글의 코드나 오래된 주소도 함께 정리합니다.
새 사이트를 받을 때에는 코드가 있다는 답변에 그치지 말고 대표 페이지의 검사 결과와 실제 화면을 대조해 달라고 요청합니다. 정확한 정보와 유지 가능한 생성 방식이 갖춰져야 이후에 글이 늘어나도 같은 품질로 관리할 수 있습니다.
담당자가 바뀌어도 유지되는 검수 방식
가정 사례로 대표자가 바뀌거나 사무소가 이전한 상황을 놓고 검수해 보세요. 화면의 소개문은 바뀌었는데 조직 정보의 주소가 남아 있을 수 있습니다. 칼럼 작성 주체와 감수자를 혼동해 실제 검토하지 않은 전문가 이름이 붙는 경우도 확인할 대상입니다. 수정 담당자는 화면과 데이터가 참조하는 원본을 찾아 같은 변경이 반영되도록 요청합니다. 게시 시각과 내용 검토 시각은 목적이 다르므로 날짜가 왜 바뀌었는지도 기록합니다.
FAQ의 경우 화면에 접어서 보여주는 질문을 하나씩 열어 답을 읽고 데이터의 질문·답과 비교합니다. 문장이 일부 잘리거나 다른 글의 답이 남아 있다면 생성 과정을 점검해야 합니다. FAQ를 새로 만들 때는 고객이 실제로 물을 만한 질문인지 먼저 검토하고, 검색용 질문을 보이지 않게 추가하지 않습니다. 글 본문을 수정하는 사람이 코드까지 매번 수작업으로 고치지 않도록 연결하는 것이 운영상 편리합니다. 홈페이지 칼럼 운영 구조와 AEO 작업과 성과의 구분도 함께 확인하세요.
자주 묻는 질문
모든 페이지에 FAQ가 필요한가요?
페이지의 질문과 목적에 맞춰 결정합니다. 실제로 설명할 질문이 없다면 검색용 코드를 위해 억지로 만들 필요는 없습니다. FAQ를 두는 페이지에서는 화면의 답변이 충분하고 본문의 조건과 일치하는지 확인한 뒤 그 내용을 데이터로 표현합니다.
검사 도구에 오류가 없으면 끝인가요?
오류가 없다는 것은 해당 도구가 검사하는 조건을 통과했다는 뜻입니다. 주소와 경력의 진위, 날짜와 본문 일치 여부는 별도 검토가 필요합니다. 공개 후에는 실제 응답에 같은 데이터가 포함되는지 확인하고 개편 때 다시 점검하도록 담당 업무에 넣으세요.
이미 플러그인이 생성하는데 추가해야 하나요?
먼저 현재 출력된 데이터를 확인하세요. 여러 도구가 같은 글 정보를 서로 다른 값으로 만들면 관리가 어려워집니다. 생성 주체와 원본 정보를 정리하고 부족한 부분만 보완하는 것이 좋습니다. 타입 개수나 속성 개수를 늘리는 자체를 목표로 삼지 않습니다.