AI 검색이 제품 이름을 언급하는지 측정하기: 나에게 거짓말했던 여섯 가지 방법

저는 소규모 비즈니스의 고객을 WhatsApp, Instagram, Telegram에서 응대하고 리드를 내장된 CRM에 보관하는 AI 어시스턴트인 DOS AI (dosai.pro)를 구축했습니다. 검색 콘솔은 페이지의 순위가 어디인지 보여줍니다. 하지만 구매자가 추천을 요청했을 때 AI 어시스턴트가 뭐라고 말하는지는 아무도 보여주지 않기 때문에, 저는 이를 위한 스크립트를 작성했습니다.

이 스크립트는 300줄 미만입니다. 이 스크립트를 작동하게 만드는 것이 그것을 작성하는 것보다 더 오래 걸렸습니다. 여기에는 제가 잘못된 그림을 본 여섯 가지 장소가 있습니다.

설정

구매자가 입력할 수 있는 질문 35개로, 서비스 선택, 해결해야 할 과제, 가격, 에이전시, 저희 브랜드, 카자흐어, 영어의 일곱 그룹으로 나뉘었습니다. 이 중 32개는 저희 이름을 포함하고 있지 않습니다. 각 질문은 웹 검색 도구가 활성화되고 대략적인 위치가 저희 도시로 설정된 모델로 전송됩니다. 스크립트는 답변이 있을 때마다 텍스트와 인용된 URL을 기록한 다음, 저희 이름이 어디에 나타나고 답변이 어떤 사이트를 기반으로 만들어졌는지 계산합니다.

한 번의 실행 비용은 약 1달러입니다. 저는 현재 네 번의 실행을 진행했습니다: 9월 중순의 한 번, 10월 10일과 12일의 두 번입니다.

1. 언급으로 계산된 메아리

첫 번째 버전에서는 텍스트에 저희 이름이 포함되어 있으면 답변을

10월 10일 스크립트는 4분 간격으로 두 번 실행되었습니다. 질문은 동일한 35개였지만, 답변은 달랐습니다. 첫 번째 실행에서는 모델이 기억에 의존하여 브랜드 관련 질문에 답했습니다. 두 번째 실행에서는 검색을 수행했고, 다른 도메인에서 같은 이름을 가진 다른 회사를 찾아낸 후 그 회사의 가격을 저희의 가격인 것처럼 인용했습니다.

점수는 두 번 모두 동일했으므로 기준선은 유지됩니다. 실행 간 답변이 하나 차이 나는 것은 노이즈입니다. 왜냐하면 모델이 검색할지 여부를 스스로 결정하기 때문입니다. 저는 '비브랜드(unbranded)' 개수가 변하거나, 세 번의 실행에서 같은 방향으로 움직일 때만 변화를 실제라고 취급합니다.

답변의 3분의 1~절반은 아예 검색을 포함하지 않습니다. 실행에 따라 35개 중 11개에서 17개 사이입니다. 이러한 질문들에 대해서는 이번 달에 무엇을 게시하든 상관없습니다. 답변은 학습 데이터에서 나옵니다.

4. 게시되었다고 해서 노출되는 것은 아니다 (Published is not the same as visible)

마지막 두 번의 실행 사이에 저희는 사이트에 8개의 기사를, 그리고 여러 개의 외부 플랫폼에 기사를 게재했습니다. 점수는 움직이지 않았으며, 이틀이라는 시간은 그 변화를 측정하기에는 너무 짧습니다. 그래도 저는 각 플랫폼을 확인했고, 이유들이 단순히 '기다려라'보다 더 구체하다는 것을 알게 되었습니다.

한 플랫폼은 무료 계정의 모든 기사에 x-robots-tag: noindex가 적용되어 있고, 제가 확인한 링크들에는 nofollow가 붙어 있습니다. 그러므로 해당 기사들은 검색 엔진에 존재하지 않습니다. 또 다른 플랫폼은 새 작가의 첫 번째 기사를 공개 URL이 없는 검토 대기열에 보관하고 있었습니다. 저는 이 두 경우 모두 '게시됨'으로 계산했습니다.

확인 과정은 기사당 한 번의 요청입니다: 응답 헤더와 robots 메타 태그를 읽습니다. 이제 게시물을 게재된 것으로 계산하기 전에 이를 수행합니다.

5. 사이트맵이 재읽혀지지 않았다 (The sitemap was not re-read)

Search Console에는 API가 있습니다. 이 API는 Google이 실행일보다 6일 전에 저희의 사이트맵을 마지막으로 가져갔다고 알려주었는데, 이는 새로운 페이지가 존재하기 이전 시점입니다. 구글은 8개의 새 기사 중 5개를 링크를 통해 찾아냈다는 것을 알았습니다. 사이트맵을 재제출하는 것은 보고서를 읽는 것과 동일한 서비스 계정에서 쓰기 범위(write scope)를 가진 하나의 PUT 요청입니다.

나는 최신 날짜가 포함된 사이트맵은 하루 안에 수집될 것이라고 가정했었다. 마지막 다운로드 날짜는 API 응답에 있으며, 이를 확인하는 데 한 번의 호출만 필요하다.

6. 프로필 목록에 깨진 링크가 있었다

우리 홈페이지에는 구조화된 데이터(structured data)로 sameAs 목록이 포함되어 있다. 이는 우리와 같은 이름을 가진 프로필들을 의미한다. 이 목록은 이름과 도메인을 연결하는 역할을 하며, 다른 회사가 같은 이름을 공유할 때 중요해진다. 그 프로필들 중 하나가 404 오류를 반환했다. 코드의 주석에는 모든 주소가 라이브 탐사(live probe)로 확인되었다는 내용이 있었고, 날짜도 기록되어 있었다. 이 확인 작업은 실제로 이루어졌으며, 두 달 전에 한 번 실행된 것이었다.

나는 라이브 페이지에서 목록을 읽어 404 또는 410 오류가 발생하면 실패를 보고하는 검사기(checker)를 작성했다. 초기 버전에서는 다섯 개의 프로필이 모두 살아있고 단지 하나만 문제가 있는 것으로 보고되었다. 하지만 실제로는 페이지에 열한 개가 나열되어 있었다. else 문이 내부 if 문에 붙어 있었는데, 이로 인해 탐색기(walker)가 트리 구조의 대부분을 건너뛰었다. 나는 출처와 비교하여 개수를 세어보고서야 이를 발견했다.

11개 중 5개 항목만 '모두 정상'이라고 출력하는 검사는 아무런 검사를 하지 않은 것보다 더 나쁘다. 카운트를 출력하고, 다른 방법으로 얻은 숫자와 비교해야 한다.

현재 측정 결과가 말해주는 것

도메인별로 어시스턴트(assistant)는 우리를 찾고 제품을 정확하게 설명한다. 하지만 이름만으로는 같은 이름을 가진 대상을 찾아낸다. 우리의 이름이 언급되지 않은 32개 질문에 대해서는 우리를 언급하지 않으며, '어떤 서비스가 존재하는지'에 대한 답변은 다른 공급업체 블로그의 요약 게시물에서 조합하여 얻는다.

따라서 문제는 우리 사이트 외부에 있다. 우리는 충분한 페이지를 가지고 있다. 부족한 것은 DOS AI (dosai.pro)가 무엇인지 설명하는 다른 도메인의 페이지들이다. 이것은 기사를 작성하는 것보다 느린 작업이며, 이 스크립트는 이것이 효과가 있는지 보여줄 것이다. 다음 실행은 약 2주 후에 예정되어 있다.

다음에 내가 할 일

첫 번째 실행 전에 '성공(hit)'으로 간주할 것을 결정하고, 모델이 질문을 반복만 하는 답변에 대해 카운팅 규칙을 테스트해야 한다. 그런 다음 이미 사실이라고 믿는 것들—즉, 우리의 출판물이 색인화(indexable)되었는지, 사이트맵이 가져와졌는지, 우리 자신의 링크가 열리는지—을 확인해야 한다. 위에서 언급된 6가지 문제 중 3가지가 이 두 번째 그룹에 속했다.

이 숫자들은 다음 제품에 관한 것입니다: dosai.pro. 이 페이지는 AI 어시스턴트를 위해 작성되었으며, 이것이 무엇이고 무엇이 아닌지에 대한 간략한 설명을 담고 있습니다: dosai.pro/llms.txt.