AI 홈페이지 —
독자가 셋인 웹사이트를 만듭니다

A 기술은 같고 완료 조건이 다릅니다. 같은 HTML·CSS·자바스크립트로 만들지만, 화면 승인만으로 끝내지 않고 검색엔진이 색인할 수 있는 상태와 답변엔진이 문단 단위로 잘라 인용할 수 있는 상태를 함께 완료 조건에 넣습니다. 특별한 제품을 사는 것이 아니라 검수 항목이 셋으로 늘어나는 것이라고 보시면 됩니다.

A 관측 몇 가지로 갈립니다. 스크립트를 끈 응답에 본문이 없고 주소 체계도 제각각이면 구조부터 새로 짓는 편이 결과적으로 빠릅니다. 본문과 주소는 멀쩡한데 robots.txt나 보안 설정 한 층에서만 막혀 있다면 사이트는 그대로 두고 접근성만 엽니다. 이미 색인과 유입이 쌓여 있다면 그것을 잃지 않는 리뉴얼이 우선입니다. 이 판정은 현황 확인 단계에서 함께 봅니다.

A 읽힐 수 있는 상태를 만드는 것까지입니다. 앞뒤로는 다른 작업이 붙습니다 — 지금 무엇이 문제인지 가르는 것은 진단이고, 인용될 문장을 쓰는 것은 콘텐츠 설계이며, 변화가 실제로 일어났는지 확인하는 것은 같은 질문의 반복 측정입니다. 이 영역이 결과를 약속하지 않는 이유도 같습니다 — 답변엔진이 무엇을 근거로 고르는지는 공개돼 있지 않고, 어느 문서를 고를지는 각 엔진이 정하고 그 기준은 공개돼 있지 않습니다. 이 한계는 AEO 진단 페이지에 조건과 함께 적어 두었습니다.

A 됩니다. 현황 확인은 공개된 상태만으로 하기 때문에 제작사가 어디인지와 무관하게 진행할 수 있고, 결과는 항목별 점검표로 그대로 드립니다. 저희에게 수정 권한이 없는 항목은 무엇을 어떻게 바꿔야 하는지 적어 드리고 적용은 담당자가 하시면 됩니다. 고쳐야 할 곳이 설정 몇 줄이면 그렇게 알려 드리는 것이 맞습니다.

A 그렇지 않습니다. 기준은 스크립트 사용 여부가 아니라 본문이 HTML 원문에 있는지입니다. 본문이 이미 원문에 담겨 있다면 그 위에서 동작하는 상호작용은 문제가 되지 않으며, 다만 스크립트가 실패해도 본문은 그대로 보이도록 만듭니다. 목록이나 탭처럼 내용이 바뀌는 요소는 스크립트 대신 정식 경로 링크로 두어 크롤러가 각각을 하나의 페이지로 읽게 합니다.

A 필수가 아닙니다. llms.txt 는 커뮤니티에서 시작된 제안이고 공식 표준이 아니며, 구글은 공식 가이드에서 검색이 이를 무시한다고 명시했습니다. 다만 파일 하나를 두는 비용이 거의 없고 사실 정보를 한곳에 정리하는 과정 자체가 도움이 되어 나비랑은 이를 선택 항목으로 제공합니다. 반드시 챙겨야 하는 쪽은 robots.txt 와 사이트맵입니다.

A 아닙니다. 사람도 세 독자 중 하나이고, 사람이 읽다 이탈하는 페이지는 검색엔진에게도 좋은 문서가 아닙니다. 나비랑은 대비·모바일·로딩 속도처럼 읽기 경험을 좌우하는 항목을 판정 대상에 포함해 관리하며, 화면 완성도와 기계 판독 구조를 맞바꾸는 방식으로 작업하지 않습니다.