본문으로 건너뛰기
유환호 의뢰하기

홈 / 인사이트

체험단·정보 플랫폼 사이트가 AI 답변에 나오려면 — 얇은 조합 페이지, 한글 브랜드명, 속도, 기준선 측정 기록으로 본 것

작성 유환호 (Hwanho Yoo) · 최종 확인 · 출처 21건

한눈에 답변

체험단 모음·정보·비교 사이트처럼 페이지를 많이 만들어 내는 플랫폼은, AI 답변보다 먼저 검색엔진이 그 페이지들을 쓸모 있는 문서로 받아들이게 해야 합니다. 지역·분야를 조합해 찍어 낸 페이지는 페이지마다 실제 데이터로 다른 내용을 채우거나, 합치거나, noindex로 검색에서 뺍니다. 구글은 사용자를 돕지 않고 순위를 노려 많은 페이지를 만드는 것을 대규모 콘텐츠 남용으로, 네이버는 비슷한 템플릿으로 문장 일부만 바꾼 페이지를 대량 발행하는 것을 스팸 사례로 적었습니다. 그 위에 주소를 하나로 모으고, 흔한 낱말 같은 서비스 이름을 어디서나 같은 표기로 쓰고, ‘이 서비스는 무엇인가’를 글자로 답하는 페이지와 Organization·WebSite 구조화 데이터를 두고, 남이 쓴 문서에 실리고, 새 페이지를 검색엔진에 알립니다. ‘추천해줘’ 답변은 여러 서비스를 늘어놓는 경우가 많으므로, 같은 질문을 같은 조건으로 반복해 그 목록에 들어가는지를 잽니다. 어느 것도 AI 답변 노출을 보장하지 않습니다.

가게 하나의 사이트와 무엇이 다른가

동네 식당이나 의원 홈페이지는 페이지가 많아야 수십 장이고, 이름은 간판에 적힌 고유한 이름이며, 손님은 그 가게가 답이 될 질문을 합니다. 체험단 모음 사이트, 공고·매물·업체를 모아 보여 주는 정보 서비스, 한 분야의 비교 사이트는 세 가지가 다릅니다.

  1. 페이지를 찍어 냅니다. 지역 × 분야 조합, 목록의 페이지 번호, 정렬·필터 조합, 수집한 항목마다의 상세 페이지가 자동으로 생깁니다. 수천, 수만 장이 되기 쉽고, 그만큼 ‘내용이 거의 같은 페이지 묶음’이 될 위험도 큽니다.
  2. 이름이 흔한 낱말로 되어 있기 쉽습니다. ‘리뷰’, ‘체험’, ‘모음’, ‘비교’처럼 하는 일을 그대로 붙인 이름은 기억하기 쉽지만, 검색엔진이 하나의 고유한 대상으로 알아보기는 어려울 수 있습니다.
  3. 답이 목록이기 쉽습니다. “체험단 사이트 추천해줘”, “OO 비교 사이트 알려줘”에 AI는 여러 서비스를 늘어놓는 경우가 많습니다(이 글에 옮긴 ChatGPT 캡처 세 장도 모두 여러 곳을 늘어놓은 표였습니다). 물어야 할 것은 첫째냐보다 그 목록에 들어가느냐입니다.

이 글은 이 세 가지를 공식 문서와, 제가 기획·개발한 체험단 공고 통합검색 서비스 리뷰로거, 기획·구축한 AEO(답변엔진 최적화) 전문 사이트 나비랑에서 남긴 기록으로 봅니다. 정본 주소, 이름 통일, 제3자 언급, 색인 알림은 따로 쓴 글이 있어 체크리스트에서 링크로 잇습니다.

찍어 낸 페이지에 대해 구글·네이버가 적은 것

구글 스팸 정책(최종 업데이트 2026-08-28)의 ‘Scaled content abuse’(대규모 콘텐츠 남용) 항목입니다.

“Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings and not helping users. This abusive practice is typically focused on creating large amounts of unoriginal content that provides little to no value to users, no matter how it’s created.”

사용자를 돕지 않고 검색 순위를 조작하려는 목적으로 많은 페이지를 만드는 것이고, 어떻게 만들었든 독창성이 없고 가치가 거의 없는 콘텐츠를 대량으로 만드는 데 초점이 있다는 뜻입니다. 예시에는 사용자에게 주는 가치가 거의 없는데 피드·검색 결과·다른 콘텐츠를 긁어 와 많은 페이지를 만드는 것, 여러 페이지의 내용을 가치를 더하지 않고 이어 붙이는 것(“Stitching or combining content from different web pages without adding value”)이 있습니다. 같은 문서의 ‘Scraping’ 항목에는 “Reproducing content feeds from other sites without providing some type of unique benefit to the user”, 다른 사이트의 피드를 사용자에게 고유한 이점 없이 다시 내보내는 것도 있습니다. 다른 사이트의 공고·상품·업체 정보를 모아 보여 주는 서비스라면 이 항목들에 비춰 자기 페이지를 따져 봐야 합니다. 대규모 콘텐츠 남용 항목 끝에는 이렇게 적었습니다.

“If you’re hosting such content on your site, exclude it from Search.”

그런 콘텐츠가 사이트에 있다면 검색에서 빼라는 뜻입니다. 지역마다 비슷한 페이지를 두는 것은 ‘Doorway abuse’ 항목과도 닿습니다. 예시 가운데 “Creating substantially similar pages that are closer to search results than a clearly defined, browseable hierarchy”, 분명한 탐색 구조라기보다 검색 결과에 가까운, 실질적으로 비슷한 페이지를 만드는 것이 있습니다.

네이버 서치어드바이저의 ‘웹 콘텐츠 스팸사례’ 문서도 같은 방향입니다. ‘저품질 콘텐츠 대량 생성’은 “검색 결과를 점유할 목적으로, 동일·유사한 템플릿을 활용하여 콘텐츠를 무의미하게 대량으로 발행하는 경우”이고, “문장 일부만 바꾼 페이지를 수십 개 이상 발행하는 방식이 이에 해당합니다.” ‘스크래핑’은 다른 사이트의 내용을 자동화 프로그램으로 복사하거나 기계적으로 변형해 거의 그대로 게시하는 경우입니다.

구글 AI 기능 문서는 AI 개요·AI 모드에 링크로 나오려면 페이지가 색인돼 있고 스니펫과 함께 검색에 나올 수 있어야 한다고 적었습니다(“a page must be indexed and eligible to be shown in Google Search with a snippet”). 검색에서 빠진 페이지는 구글 AI 기능의 링크 후보도 아니라는 뜻입니다. 구글의 생성형 AI 검색 가이드(최종 업데이트 2026-07-10)는 흔하지 않은(non-commodity) 콘텐츠를 만들라고 하면서, 기존 콘텐츠의 요약은 “simply restates information already available elsewhere”, 이미 다른 곳에 있는 정보를 다시 말할 뿐이라고 적었습니다. 모아 보여 주는 서비스가 원본에 없는 무엇을 더하느냐가 검색과 AI 답변에서 같은 질문이 된다는 것이 제 해석입니다.

리뷰로거에서 남긴 기록

리뷰로거(reviewloger.com)는 체험단 플랫폼 61곳의 공고를 3시간마다 모아 지역·마감·경쟁률로 보여 주는 체험단 공고 통합검색 서비스입니다. 저는 기획·개발·수집 파이프라인·SEO·AEO를 맡았습니다(프로젝트).

공고 218건이 있어도 1000위 안에 없던 조합 페이지

2026년 7월 ‘서울 뷰티 체험단’ 페이지에는 실제 공고가 218건 있었고, 사이트맵에 있었고, 다른 페이지와 공고가 겹치지도 않았습니다. 그런데 07-17부터 07-30까지 매일 잰 순위에서 1000위 안에 한 번도 없었습니다. 공고 카드를 걷어 내고 남은 설명 문장을 비교해 보니, 지역·분야 조합 페이지 250개가 지역명·분야명·건수만 다르고 문장 구조는 같았습니다.

페이지마다 실제 공고 집합에서 유형 구성, 마감 3일 이내 비율, 경쟁률 중앙값, 구군별 분포, 출처 분포를 계산해 직답 문단으로 넣었습니다. 해설 문장은 붙이지 않았습니다. 해설이 다시 템플릿이 되기 때문입니다. 표본이 5건 미만이면 경쟁률을 말하지 않았고, ‘신청자가 적은 편’ 같은 표현이 수십 페이지에 같은 문장으로 박히는 것을 보고 숫자(%)로 바꿨습니다. 같은 순위 확인 도구로 다시 재니 같은 페이지(/category/beauty/seoul)가 08-03에 3위, 08-24에 16위였습니다.

한계도 사례에 적은 그대로 옮깁니다. 같은 주에 IndexNow 수정(07-28)·사이트맵 선별(07-29)·구글 색인 정비(07-31)도 배포해 이 문단 하나의 효과로 단정할 수 없고, 3위에서 16위로 내려간 사이(08-12·08-13)에도 다른 수정이 배포됐습니다. 이 사례에서 AI 답변은 재지 않았습니다(사례, 기록).

상세 페이지 15,831장은 열지 않았고, 빈 페이지 번호는 404 대신 noindex

같은 달, 수집한 공고 상세 페이지 15,831장을 검색에서 빼 둔 판단을 숫자로 다시 확인했습니다. 고유한 본문을 가진 페이지는 0건이었고, 평균 49자짜리 요약문의 39%와 제목의 24%가 다른 페이지와 글자까지 같았습니다(한 제목이 최대 23개 URL에서 반복). 같은 공고가 여러 플랫폼에 올라오면 따로 쌓이는 구조 때문이었습니다. 그래서 색인 제외는 유지하고, 이 페이지들에서 나가는 내부 링크까지 막던 설정만 풀었습니다. 다시 열 조건은 플랫폼 간 중복 병합, 원본에 없는 정보 블록 추가, 그 블록이 페이지마다 실제로 다른지 검증, 오래 남는 공고 일부로 제한 실험 — 넷을 모두 채우는 것으로 정했습니다(기록).

목록 주소에 존재하지 않는 큰 페이지 번호를 붙여도 200 응답에 카드 0개인 빈 페이지가 색인 허용 상태로 열리는 구멍도 있었습니다. 이것은 404가 아니라 noindex로 막았습니다. 공고가 몇 시간마다 마감돼 오전의 10페이지가 오후에 8페이지로 줄 수 있어, 몇 시간 전까지 있던 페이지에 ‘이 주소는 없다’는 404를 주기보다 열어 둔 채 색인에서만 빼는 쪽을 골랐습니다(제 판단입니다). 공고가 0건이어도 1페이지는 그 자체가 답이라 예외로 뒀습니다(기록).

한글 이름 ‘리뷰로거’는 0건이었다

2026년 7월, 영문 ‘reviewloger’로는 40여 페이지가 검색되는데 한글 ‘리뷰로거’로는 0건이었습니다. 신조어가 ‘리뷰’와 ‘로거’로 쪼개져 아주 흔한 낱말 ‘리뷰’에 신호가 묻히는 것으로 추정했고, 홈 <h1>에는 브랜드 이름이 없었습니다. 홈 <h1>에 이름을 넣고, Organization·WebSite 구조화 데이터의 alternateName으로 한글·영문 표기를 잇고, 홈 본문에서 두 표기를 한 문장에 묶었습니다. 그 뒤 ‘리뷰로거’가 77위로 처음 잡혔지만 이틀 뒤 다시 300위 밖으로 벗어났습니다. 한 사이트·한 검색어의 관측이고 대조군이 없어, 수정 때문인지 시간이 지나서인지 나누지 못했습니다(사례, 기록).

8월 24일 기록에는 다른 걸림돌도 있습니다. 브랜드 이름을 그대로 쳤는데 검색엔진이 비슷한 다른 표기로 바꿔 검색했고, 웹문서 검색에서는 1위였던 이 도메인이 바뀐 결과에는 한 건도 없었습니다. 코드로 고칠 문제가 아니라 검색엔진의 공식 창구에 요청할 일로 봤고, 같은 검색어를 반복해 자동으로 검색하는 방식은 쓰지 않았습니다(기록).

모바일 성능 66점에서 99점

2026년 7월 리뷰로거의 모바일 PageSpeed 성능은 66점이었습니다. 글꼴 로딩 차단을 풀고 큰 썸네일을 줄여도(모바일 512KiB 절감) 목표에 못 미쳤고, 다시 뜯어보니 카드마다 걸린 복잡한 CSS 선택자의 재계산(4배 CPU 스로틀에서 스타일·레이아웃 계산 800ms 이상)과 애널리틱스 스크립트가 병목이었습니다. 선택자를 클래스로 바꾸고, 애널리틱스를 로드 1.5초 뒤에 넣고, 엣지 캐시를 다시 구현하는 등의 수정 뒤 모바일 99점(데스크톱 전 항목 100점), 홈 서버 응답 930ms → 270ms가 됐습니다. 엣지 캐시는 첫 배포 직후 빈 본문을 내보내 몇 분 만에 되돌렸다가 다시 만들었습니다.

카드 목록이 길게 이어지는 것은 플랫폼 사이트의 기본 모양이라, 병목이 이미지보다 카드의 CSS에 있었다는 점을 적어 둡니다. 다만 성능 개선이 검색 순위나 AI 답변 노출에 준 영향은 따로 재지 않았습니다(사례, 기록). 구글 AI 기능 문서도 좋은 페이지 경험(“Providing a great page experience for users”)을 AI 개요·AI 모드에서도 계속 유효한 SEO 기본기의 하나로 들 뿐, 속도가 AI 답변 인용에 얼마나 작용하는지는 밝히지 않았습니다.

ChatGPT 답변 — 표 첫 줄, 출처로도 인용

2026년 10월 13일 ChatGPT에 ‘블로그 체험단 사이트 모음 사이트 알려줘’를 물은 답변 캡처에서 리뷰로거는 답변 표의 첫 줄(‘61개 체험단 사이트 공고 통합’)이었고, 아래 문단 끝에 출처 표시 ‘리뷰로거’가 붙었습니다. 같은 표의 다른 줄에는 다른 사이트들이 있었습니다(캡처에서는 이름을 회색으로 가렸습니다). 답이 목록이라는 것을 그대로 보여 주는 화면입니다.

답변의 ‘61개’는 2026년 10월 26일에 확인한 리뷰로거 홈 제목의 ‘체험단 사이트 61곳’과 같은 숫자지만, 답변이 어느 문서를 읽었는지는 화면만으로 알 수 없습니다. 질문 하나에 한 번의 캡처이고, 날짜는 캡처가 공유된 날이며 화면에 시각은 없습니다. 같은 조건으로 횟수를 센 측정이 아니고, 작업 전 기준선도 없습니다. 실제 화면은 프로젝트 페이지에 있습니다.

나비랑에서 남긴 기록

나비랑(navirang-ai.com)은 AEO(답변엔진 최적화) 전문 사이트입니다. 체험단 사이트는 아니지만 정보 구조를 넓히며 상업 페이지를 묶음으로 늘린 사이트이고, ‘전문업체 알려줘’처럼 답이 목록인 질문에서 후보가 되는 사이트입니다. 저는 기획·구축·SEO·AEO·GEO·AI 답변 측정 설계를 맡았습니다(프로젝트).

IndexNow 뒤 며칠째 0건, 직접 수집 요청한 날 1위

2026년 8월, 새로 만든 상업 페이지 하나가 IndexNow를 보낸 지 며칠이 지나도 페이지 제목을 그대로 네이버에 검색하면 0건이었습니다. 감사해 보니 초기 글·지역 페이지는 잡혀 있고, 정보 구조를 넓히며 새로 만든 상업 페이지만 통째로 빠져 있었습니다. 네이버 서치어드바이저에서 수집을 직접 요청하자 같은 날 오전 제목 검색 1위로 잡혔고, 같은 날(08-25) 상업적 전환에 가까운 순서로 정한 14건을 같은 방식으로 요청하자 몇 분 뒤 재감사에서 14건 모두 잡혔습니다(9건은 제목 검색 1위, 나머지는 2·5·6·22·33위).

색인 누락은 ‘페이지 제목을 그대로 검색해도 0건’일 때로만 판정했습니다. 한계는 요청하지 않았어도 잡혔을지 가릴 대조군이 없다는 것, 그리고 제목 그대로의 검색 순위이지 사람들이 실제로 치는 검색어의 순위가 아니라는 것입니다. 이 사례에서 AI 답변은 재지 않았습니다(사례, 기록). 페이지를 묶음으로 늘리는 사이트에서는 새 묶음이 통째로 빠져 있는 일이 생길 수 있다는 기록입니다.

ChatGPT 답변 — 표 첫 줄, 출처는 화면에서 확인 안 됨

2026년 10월 13일 ChatGPT에 ‘AI 상위노출 전문업체 알려줘’와 ‘AEO 답변엔진 최적화 전문업체 알려줘’를 물은 두 답변 캡처에서 나비랑은 모두 답변 표의 첫 줄이었습니다. 이것도 여러 곳을 표로 늘어놓은 답변이었고(다른 업체 줄은 가렸습니다), 출처로 인용됐는지는 화면에서 확인되지 않습니다. 아래 280셀 측정 조건으로 잰 것이 아닙니다(사례).

280셀 기준선은 아직 재지 않았다

나비랑의 측정 설계는 질문 40개(개념 10·업체 탐색 10·브랜드 지정 8·지역 7·데이터 5) × 답변엔진 7개(ChatGPT·구글 AI 개요·Perplexity·Claude·네이버 AI 검색·Copilot·Gemini) = 280셀을 기준선으로 먼저 재고, 사이트를 바꾼 뒤 같은 조건(로그아웃 세션, 새 대화, 매주 같은 요일·시간대, 같은 문구, 분모 280 고정)으로 다시 재는 것입니다. 셀마다 언급·인용·추천을 따로 세고 함께 언급된 경쟁사도 적습니다. 이 글을 쓰는 2026년 10월 26일까지 기준선은 측정 전이라, 언급률·인용률 숫자는 하나도 없습니다. 위 캡처 두 장으로 비율을 말할 수도 없습니다(연구).

플랫폼 사이트 체크리스트

1. 찍어 낸 페이지는 채우거나, 합치거나, 뺀다. 카드 목록을 걷어 낸 나머지 문장을 페이지끼리 비교해 봅니다. 숫자와 지명만 다르면 그 페이지 데이터로만 계산되는 값을 넣거나, 비슷한 페이지를 하나로 합치거나, noindex로 뺍니다. 구글 페이지네이션 문서는 같은 목록의 정렬·필터 변형이 색인되지 않게 noindex로 막거나 robots.txt로 그 주소 패턴의 크롤을 막으라고 하고, 2페이지 이후를 1페이지로 정본 처리하지 말고 각 페이지에 자기 정본 주소를 주라고 적었습니다. 패싯 탐색 문서도 색인할 필요가 없는 필터 주소라면 크롤을 막는 쪽을 먼저 듭니다.

다만 noindex를 건 페이지를 robots.txt로 함께 막으면 안 됩니다. 구글 noindex 문서는 “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file”이라고, robots.txt로 막히면 크롤러가 noindex를 보지 못하고 다른 페이지가 링크하면 검색 결과에 나올 수 있다고 적었습니다. 리뷰로거에서도 모든 화면의 머리·바닥이 링크하던 개인·즐겨찾기·의견 보내기 페이지 세 곳에 noindex와 robots 차단이 함께 걸려 있어 차단을 풀었습니다. 반대로 목록 경로 2,400여 개에 정렬·필터를 곱해 2만 개가 넘는 사본 주소는 크롤 자체를 막아 뒀습니다(기록).

2. 주소는 하나로. 같은 목록이 파라미터 순서·끝 슬래시·http/www 차이로 여러 주소에서 열리지 않게 301, rel=canonical, 사이트맵을 맞춥니다. 리뷰로거에는 네이버 기준으로 두었던 정렬·범위 파라미터를 구글 수집기가 따라가 약 2만 개 URL이 생긴 기록이 있습니다(기록). 방법은 한 페이지 한 주소에 있습니다.

3. 이름은 하나로, 다른 표기는 별칭으로. 구글 사이트 이름 문서는 “Best Dentists In Iowa” 같은 일반 명사형 이름은 아주 잘 알려진 브랜드가 아니면 사이트 이름으로 선택되기 어렵다고 적었고, 홈페이지에서 이름을 일관되게 쓰고 다른 표기는 alternateName으로 주라고 합니다. 네이버 스팸 사례 문서는 ‘실제 명칭 대신 검색량이 많은 키워드로 치환하여 작성하는 경우’를 키워드 반복·남용으로 듭니다. 이름 자리를 ‘체험단 모음’ 같은 검색어로 바꾸지 말고, 이름과 하는 일을 함께 적습니다. 자세한 방법은 엔티티 일관성에 있습니다.

4. ‘이 서비스는 무엇인가’를 글자로 답하는 페이지. 소개 페이지 한 장에 무엇을 모으는지, 어디서 가져오는지, 무엇을 하지 않는지, 원본과 어떤 관계인지, 누가 만들었는지를 적습니다. 2026년 10월 26일에 연 리뷰로거 소개 페이지는 첫 문단을 서비스 정의 한 문장으로 시작하고, ‘누구를 위한 서비스인가요?’, ‘리뷰로거가 하는 일 / 하지 않는 일’(체험단을 직접 모집·운영하지 않고, 원본 공고 문장을 복제하지 않고 자체 형식으로 요약), ‘원본 체험단 플랫폼과의 관계’(각 사이트의 robots.txt 준수, 수집 중단을 요청한 플랫폼은 제외, 정확한 내용은 원본 우선), 만든 사람을 차례로 적었습니다. 구글 AI 기능 문서는 중요한 내용을 텍스트로 두라고(“Making sure that important content is available in textual form”) 적었습니다. AI가 ‘OO는 어떤 사이트야?’에 답할 때 옮길 문장이 페이지에 있어야 한다는 것이 제 판단입니다.

5. Organization·WebSite 구조화 데이터. 구글 사이트 이름 문서에 따르면 WebSite는 홈페이지(도메인·서브도메인 루트)에 있어야 하고 name·url이 필수, alternateName은 권장입니다. Organization 문서는 필수 속성이 없다고 하고, 홈페이지나 소개 페이지처럼 조직을 설명하는 페이지 한 곳에 두기를 권하며(모든 페이지에 넣을 필요는 없음), name·alternateName은 사이트 이름과 같게 쓰라고 합니다. 구글 AI 기능 문서는 구조화 데이터가 화면 글자와 맞게 하라고(“Making sure your structured data matches the visible text on the page”) 적었습니다. 같은 날 확인한 리뷰로거 홈은 제목이 ‘블로그 체험단 모음 | 체험단 사이트 61곳 한 번에 비교 - 리뷰로거’, <h1>이 ‘리뷰로거’로 시작하고, Organization·WebSite의 name은 ‘리뷰로거’, alternateName은 reviewloger·Reviewloger·리뷰 로거·reviewloger.com이었습니다. 기대치도 적어 둡니다. 구글 생성형 AI 가이드는 생성형 AI 검색에 구조화 데이터가 필수가 아니고 따로 넣을 특별한 schema.org 마크업도 없다고 밝혔습니다. 리치 결과 자격에 도움이 되니 SEO의 일부로는 계속 쓰라고 덧붙였습니다.

6. 남이 쓴 문서에 실린다. 나비랑에서 ‘추천해줘’ 페이지를 만들며 남긴 기록에는, 이 질문은 목록을 요구하므로 한 회사를 아무리 잘 설명해도 그것만으로 답이 되지 않고, 후보 명단은 대개 여러 곳을 같은 기준으로 다룬 제3자 문서에서 나온다는 판단이 있습니다(기록). 연구 수치와 정직하게 늘리는 법, 하면 안 되는 일은 제3자 언급에 정리했습니다.

7. 색인 알림은 열어 둔 페이지만. 사이트맵에는 색인할 정본만 넣고, 내용이 바뀐 주소만 IndexNow로 보내고, 중요한 새 페이지 묶음은 서치 콘솔·서치어드바이저에서 직접 요청합니다. noindex로 뺀 수천 장을 사이트맵과 알림에 섞으면 스스로 낸 신호끼리 어긋난다고 봅니다(제 판단입니다). 엔진별 방법은 새 글을 검색엔진에 알리는 법에 있습니다.

8. 그리고 잰다. ‘체험단 사이트 추천해줘’처럼 실제로 물을 질문을 고정하고, 엔진·세션 조건·횟수를 정한 뒤, 목록에 들어갔는지(언급)·출처로 붙었는지(인용)·함께 나온 서비스는 어디인지를 따로 적습니다. 분모는 처음에 정하고 바꾸지 않습니다. 계산은 언급률·인용률 계산법에, 혼자 확인하는 순서는 직접 확인하는 법에 있습니다.

맡길 곳을 고를 때

혼자 하든, 회사(대행사)나 개인 실무자에게 맡기든, 플랫폼 사이트라면 먼저 물을 것은 같습니다.

  • 찍어 낸 페이지 가운데 무엇을 열고 무엇을 뺄지, 중복 비율 같은 근거 숫자와 함께 설명하는가
  • 고치기 전에 기준선(색인 상태, 브랜드명 검색, 정해 둔 질문의 AI 답변)을 먼저 재는가
  • AI 답변 노출이나 순위를 보장한다고 말하지 않는가
  • 바꾼 내용과 측정 원자료를 넘겨받을 수 있는가

더 자세한 기준은 AI 상위노출 전문가 고르는 기준에 있습니다.

저도 그 선택지 가운데 하나입니다. 유환호는 회사가 아니라 개인으로 일하고, 진단부터 구축·수정까지 직접 합니다. 수집 데이터로 생긴 페이지를 열 것과 뺄 것으로 나누고, 주소·이름·구조화 데이터를 코드에서 정리하고, 측정 조건을 정해 다시 재는 일이 제가 하는 일입니다. 부족한 점도 있습니다. 같은 조건으로 반복 측정한 AI 답변 결과는 리뷰로거·나비랑 어느 쪽에도 아직 없습니다(아래 ‘아직 모르는 것’). 순위·노출·기간은 보장하지 않습니다. 비용은 사이트 규모와 맡길 범위를 보고 견적으로 정합니다. 문의는 연락하기의 이메일로 받습니다.

아직 모르는 것

  • 리뷰로거의 조합 페이지·한글 브랜드명·속도 기록과 나비랑의 수집 요청 기록은 모두 검색 단계의 기록이고, 각 사례에서 AI 답변은 재지 않았습니다. 이 작업들이 2026년 10월 13일 캡처의 표 첫 줄과 어떻게 이어지는지는 알 수 없습니다.
  • 캡처는 ChatGPT 한 엔진, 질문마다 한 번의 화면입니다. 같은 질문을 다른 엔진에는 묻지 않았습니다.
  • 나비랑 280셀 기준선은 측정 전입니다. 재면 이 글에 날짜와 함께 덧붙입니다.
  • 기록마다 사이트 한 곳의 관측이고 대조군이 없어, 다른 플랫폼 사이트에서 같은 결과를 기대할 근거는 아닙니다.

이 글을 쓴 사람

이 글은 AI 상위노출(AI 검색 노출) 작업을 하는 유환호가 썼습니다. 이 주제로 일을 하고 있으므로 이해관계가 있습니다. 본문의 리뷰로거·나비랑 기록은 그가 만든 사이트에서 나온 것이고, 각 사례·기록 페이지에 한계를 함께 공개했습니다. 인용한 구글·네이버 서치어드바이저 문서와 리뷰로거 홈·소개 페이지 HTML은 2026년 10월 26일에 원문을 열어 대조했습니다. 문서 내용이 바뀌거나 기준선을 재면 이 글에 날짜와 함께 고칩니다.

자주 묻는 질문

‘체험단 사이트 추천해줘’ 답변에 우리 사이트가 나오게 하려면 무엇부터 하나요?
검색엔진이 사이트를 제대로 받아들이게 하는 일부터 합니다. 지역·분야 조합이나 수집한 항목의 상세처럼 찍어 낸 페이지 가운데 내용이 거의 같은 것은 고유한 데이터로 채우거나 합치거나 noindex로 빼고, 주소를 하나로 모으고, 서비스 이름을 어디서나 같은 표기로 씁니다. 그다음 ‘이 서비스는 무엇인가’를 글자로 답하는 소개 페이지와 Organization·WebSite 구조화 데이터를 두고, 남이 쓴 비교·소개 글에 같은 이름으로 실리는 길을 찾습니다. ‘추천해줘’ 답변은 여러 서비스를 늘어놓는 목록인 경우가 많아, 같은 질문을 같은 조건으로 반복해 그 목록에 들어가는지 재야 변화를 말할 수 있습니다. 어느 것도 노출을 보장하지 않습니다.
지역·분야 조합 페이지를 수백 개 만들어도 괜찮나요?
페이지마다 다른 내용이 있느냐에 달렸습니다. 구글 스팸 정책은 사용자를 돕지 않고 순위를 노려 많은 페이지를 만드는 것을 대규모 콘텐츠 남용(scaled content abuse)으로 보고, 그런 콘텐츠가 있으면 검색에서 빼라고 적었습니다. 네이버 서치어드바이저도 동일·유사한 템플릿으로 문장 일부만 바꾼 페이지를 수십 개 이상 발행하는 것을 스팸 사례로 듭니다. 리뷰로거에서는 공고 218건이 있던 ‘서울 뷰티 체험단’ 페이지가 지역명·분야명·건수만 다른 같은 문장 속에서 1000위 안에 없었고, 페이지 데이터로 계산한 통계 문단으로 바꾼 뒤 같은 도구로 2026년 8월 3일 3위, 8월 24일 16위였습니다. 같은 주에 다른 색인 정비도 배포해 이 변경 하나의 효과로 단정하지는 않습니다.
서비스 이름이 흔한 낱말이라 이름으로 검색해도 잘 나오지 않습니다.
홈 h1에 이름을 넣고, 구조화 데이터 alternateName으로 한글·영문 표기를 잇고, 본문에서 두 표기를 한 문장에 함께 적고, 바깥에서 같은 이름으로 언급되게 하는 순서로 봅니다. 구글 사이트 이름 문서는 ‘Best Dentists In Iowa’ 같은 일반 명사형 이름은 아주 잘 알려진 브랜드가 아니면 사이트 이름으로 선택되기 어렵다고 적었습니다. 리뷰로거는 2026년 7월 한글 이름 검색 0건이었고, 이렇게 고친 뒤 77위로 처음 잡혔다가 이틀 뒤 300위 밖으로 밀렸습니다. 대조군이 없어 수정 때문인지 시간이 지나서인지는 나누지 못했고, 코드만으로 끝나지 않고 실제로 그 이름을 검색하는 양이 쌓여야 하는 부분이 남는다는 기록입니다.
AI 답변에 우리 서비스가 얼마나 나오는지는 어떻게 재나요?
실제로 물을 질문을 정해 두고, 엔진·로그아웃 여부·새 대화·반복 횟수 같은 조건을 고정해 다시 묻습니다. 목록에 이름이 나왔는지(언급), 출처로 붙었는지(인용), 함께 나온 서비스는 어디인지를 따로 적고, 분모는 처음에 정한 뒤 바꾸지 않습니다. 나비랑은 질문 40개 × 답변엔진 7개 = 280셀을 기준선으로 설계했지만 2026년 10월 26일까지 기준선은 측정 전이라 비율은 없습니다. 한 번 찍은 캡처는 그날 그 답변에 나왔다는 기록이지 비율이 아닙니다.

출처

아래 출처는 전부 원문을 열어 확인한 것입니다. 확인 날짜: 2026-10-26

  1. [1] Spam policies for Google web search Google 검색 센터 (최종 업데이트 2026-08-28) · 공식 문서
  2. [2] Optimizing your website for generative AI features on Google Search Google 검색 센터 (최종 업데이트 2026-07-10) · 공식 문서
  3. [3] AI features and your website Google 검색 센터 (최종 업데이트 2025-12-10) · 공식 문서
  4. [4] Block Search indexing with noindex Google 검색 센터 (최종 업데이트 2025-12-10) · 공식 문서
  5. [5] Pagination, incremental page loading, and their impact on Google Search Google 검색 센터 (최종 업데이트 2025-12-10) · 공식 문서
  6. [6] Managing crawling of faceted navigation URLs Google 크롤링 인프라 문서 (최종 업데이트 2025-12-18) · 공식 문서
  7. [7] Provide a site name to Google Search Google 검색 센터 (최종 업데이트 2025-12-10) · 공식 문서
  8. [8] Organization (Organization) structured data Google 검색 센터 (최종 업데이트 2026-09-08) · 공식 문서
  9. [9] 웹 콘텐츠 스팸사례 네이버 서치어드바이저 (2026-10-26 확인) · 공식 문서
  10. [10] 리뷰로거 — 공고 218건이 있는데도 색인이 안 된 250개 조합 페이지 hwano-ai.com · 자체 기록
  11. [11] 열어도 안전해 보이는 페이지 15,831장을 열지 않기로 했다 유환호 기록 · 자체 기록
  12. [12] 존재하지 않는 페이지 번호를 404로 막지 않은 이유 유환호 기록 · 자체 기록
  13. [13] 의심했던 페이지는 안전했고, 진짜 물린 곳은 따로 있었다 유환호 기록 · 자체 기록
  14. [14] 리뷰로거 — 영문 브랜드는 40여 페이지, 한글 브랜드는 0건이었다 hwano-ai.com · 자체 기록
  15. [15] 브랜드명을 검색했더니 검색엔진이 마음대로 다른 말로 바꿔 검색했다 유환호 기록 · 자체 기록
  16. [16] 리뷰로거 — 모바일 성능 66점을 99점으로, 진짜 병목은 이미지가 아니었다 hwano-ai.com · 자체 기록
  17. [17] 리뷰로거 프로젝트 — ChatGPT ‘블로그 체험단 사이트 모음 사이트 알려줘’ 답변 캡처(2026-10-13) hwano-ai.com · 자체 기록
  18. [18] 리뷰로거 소개 페이지와 홈 HTML (2026-10-26 확인 — 제목·h1·Organization·WebSite alternateName) 리뷰로거 · 자체 기록
  19. [19] 나비랑 — IndexNow로 며칠째 안 잡히던 페이지가 수동 수집 요청 당일 1위 hwano-ai.com · 자체 기록
  20. [20] 나비랑 — AI 답변 인용 개선 실험, 기준선을 재기 전에는 아무 숫자도 내지 않는다 hwano-ai.com · 자체 기록
  21. [21] 설명을 아무리 잘 써도 ‘추천해줘’라는 질문에는 답이 안 된다 유환호 기록 · 자체 기록

같은 주제의 다른 글

우리 사이트가 어느 단계에서 막혀 있는지 확인받고 싶다면 사이트 주소와 고객이 물을 법한 질문 두세 개를 보내 주세요. 연락하기 →

→

사이트 둘러보기