W2Tips

W2가 검색에 나오지 않을 때 먼저 볼 5가지

2026년 9월 9일8분 읽기

W2로 운영하는 사이트의 색인 수가 어느 주부터 갑자기 줄었습니다. 사이트는 바꾸지 않았는데, 그 시기에 보안 강화로 WAF 설정을 바꿨습니다. W2로 3개 브랜드를 운영하면서 브랜드마다 도메인을 따로 두었는데 어느 브랜드도 검색에서 약하고, 하나로 모았어야 했는지 알 수 없습니다. 자사 기반으로 운영하는 숍에서 들어오는 문의는 이 두 가지에 몰려 있습니다.

둘 다 HTML을 손대지 않았는데 검색 엔진이 보는 사이트가 달라진다는 점이 같습니다. WAF 설정 변경은 "사이트 변경"이고, 도메인은 "검색 엔진에게 회사의 단위"입니다. 이 글에서는 개별 글에서 정리한 내용을 "먼저 볼 5가지" 순서로 다시 묶습니다. 수치와 절차는 각 글의 내용을 그대로 쓰고, 자세한 작업은 글 끝의 링크로 넘깁니다.

1. 색인 수가 갑자기 줄었다면 WAF를 바꾼 날짜를 적고 Search Console의 크롤 통계와 맞춰 본다

먼저 의심할 것은 WAF나 봇 대책입니다. 검색 엔진과 AI 크롤러를 공격적인 봇으로 판정하는 경우가 있고, 판정된 크롤러는 그대로 막힙니다. 크롤러는 짧은 시간에 많은 요청을 보내기 때문에 속도 제한이나 행동 감지에 걸리기 쉽습니다. 막히면 Googlebot에는 오류(403, 429, 5xx)가 돌아가고, 색인이 줄면서 순위도 떨어집니다. 사이트의 HTML은 그대로라 원인을 알아차리기 어려운 상태가 이어집니다.

확인	보는 곳	차단의 징후
크롤 응답	Search Console 설정 → 크롤 통계	403·429·5xx의 비율이 늘고 있다
수집 가능 여부	Search Console URL 검사 → 실시간 테스트	"가져올 수 없음"
서버 로그	WAF·웹 서버 로그	Googlebot·GPTBot 등의 User-Agent에 대한 403·429
WAF의 차단 로그	WAF 관리 화면	정규 크롤러의 IP가 차단 대상에 포함되어 있다

Search Console에서는 설정에서 크롤 통계를 열어 "호스트 상태"에 문제가 없는지, "응답별" 내역에서 403·429·5xx가 늘어난 시기가 언제인지 보고, 주력 페이지의 실시간 테스트로 가져올 수 있는지 확인합니다. 실시간 테스트에서 가져올 수 없다면 그 시점에 Googlebot은 막혀 있습니다. 며칠 정도의 차단이라면 해제 후에 회복되지만, 몇 주 이어지면 색인에서 빠지는 페이지가 생기고 회복에도 시간이 걸립니다. CDN에도 봇 대책이 있어 WAF와 이중으로 막고 있는 경우가 있으니 CDN 로그도 함께 봅니다.

2. 서버 로그에서 정규 크롤러에 대한 403·429를 찾고, IP로 검증해 허용 목록에 넣는다

WAF 또는 웹 서버의 액세스 로그를 User-Agent에 Googlebot, bingbot, GPTBot, ClaudeBot, PerplexityBot 등을 포함하고 응답 코드가 403, 429, 5xx인 조건으로 거릅니다. 해당하는 요청이 있으면 어떤 규칙에 걸렸는지 WAF 로그에서 찾습니다. User-Agent는 위장할 수 있으므로 허용 목록에는 IP 검증을 함께 씁니다.

크롤러	검증 방법
Googlebot	Google이 공개하는 IP 주소 범위(JSON)와 대조하거나, 역방향 DNS로 googlebot.com을 확인
bingbot	Bing이 공개하는 IP 범위와 대조
GPTBot·OAI-SearchBot	OpenAI가 공개하는 IP 범위와 대조
ClaudeBot	Anthropic이 공개하는 정보와 대조
PerplexityBot	Perplexity가 공개하는 IP 범위와 대조

각사의 공개 IP는 바뀌므로 허용 목록도 정기적으로 갱신합니다. 속도 제한의 임계값은 크롤 통계에서 확인할 수 있는 Googlebot의 평소 크롤 빈도를 밑돌지 않는 값으로 둡니다. Googlebot의 크롤 빈도는 예전에는 Search Console에서 낮출 수 있었지만 지금은 자동 조정만 남아 있고, 사이트가 느리거나 오류가 많으면 자동으로 줄어듭니다. 속도 제한으로 막기보다 사이트 쪽 응답을 안정시키는 편이 확실합니다.

3. AI 크롤러의 허용·거부는 방침으로 정하고, 거부는 WAF가 아니라 robots.txt로 한다

AI 크롤러를 허용할지 거부할지는 기술이 아니라 방침의 문제입니다. 설정을 만지기 전에 세 가지 중 하나를 정합니다.

방침	의미	설정
검색 엔진도 AI도 허용	AI 검색에서의 인용을 노린다	모든 정규 크롤러를 허용 목록에
검색 엔진은 허용, AI 학습용은 거부, AI 검색용은 허용	인용은 원하지만 학습에는 쓰이게 하지 않는다	GPTBot(학습)은 거부, OAI-SearchBot(검색)은 허용 등
검색 엔진만 허용	AI 검색에 나오지 않아도 된다	AI 크롤러를 robots.txt로 거부

거부한다면 WAF가 아니라 robots.txt로 하는 것이 기본입니다. WAF로 막으면 크롤러는 이를 오류로 기록하고, 그 기록이 사이트 건전성 평가에 영향을 주기도 합니다. robots.txt의 거부는 의도적인 거부로 취급됩니다. 설정을 바꿀 때는 WAF·봇 대책·속도 제한의 변경을 날짜와 내용으로 기록하고, 변경 후 1주일간 크롤 통계에서 응답 코드를 확인하며, 허용 목록을 갱신하기 전에 각사의 최신 IP 범위를 가져옵니다. WAF 설정은 보안 담당이 바꾸고 SEO 담당은 모르는 상황이 전형적입니다. 한 번 확인해서 문제가 없어도 다음 설정 변경에서 다시 생기므로, WAF를 바꾸면 SEO 담당에게 알리는 규칙부터 정합니다.

4. 멀티브랜드의 도메인 구성은 브랜드의 독립성과 평가의 집약 사이에서 정한다

도메인을 나누면 각 브랜드는 독립하지만 평가는 셋으로 흩어집니다. 한 도메인의 서브디렉터리로 모으면 평가는 모이지만 브랜드가 "한 회사의 상품 라인"으로 보입니다. 정답은 브랜드가 정말 독립된 존재로 인지되어야 하는지에 달려 있습니다. 검색 엔진에게 도메인은 회사의 단위라서 나누면 별개 회사, 모으면 한 회사로 봅니다. 브랜드 전략에서 정한 방향을 도메인이 뒤집지 않게 합니다.

구성	평가의 축적	브랜드의 독립성	운영 부하	적합한 경우
별도 도메인	분산	높음	높음(Search Console·사이트맵·robots가 각각)	브랜드가 개별적으로 인지되고, 서로 관련짓고 싶지 않다
서브도메인	거의 분산(근래에는 동일 사이트 취급 경향)	중간	중간	브랜드의 독립성을 유지하면서 기업으로서의 연결도 보여주고 싶다
서브디렉터리	집약	낮음	낮음	한 회사의 상품 라인으로 취급되어도 괜찮다. 평가의 집약을 우선

판단은 다섯 질문으로 합니다. 브랜드명으로 검색되고 있는가, 브랜드 간에 고객층이 다른가, 각 브랜드에 전담 운영 담당자가 있는가, 공통 상품이 많은가, 기업명으로 인지를 높이고 싶은가. "예"가 많을수록 분리, "아니요"가 많을수록 집약이고, 망설여지면 서브도메인입니다. Google은 근래 서브도메인과 서브디렉터리를 크게 구별하지 않는다고 밝혔지만 명확히 보증한 것은 아니므로, 확실히 모으고 싶다면 서브디렉터리를 고릅니다. 7.5만 브랜드를 분석한 Ahrefs의 연구에서 AI Overviews 노출과 가장 강한 상관을 보인 신호는 백링크 수(0.218)가 아니라 브랜드의 웹상 언급(0.664)이었습니다. 별도 도메인에서 서브디렉터리로 통합하는 것은 가능하지만, 구 도메인 전 URL의 리다이렉트, Search Console의 주소 변경, 구조화 데이터 재설계가 따르는 사이트 이전 규모의 작업입니다.

5. 공통 상품의 canonical과 Organization을 구성에 맞춰 설계한다

여러 스토어에서 같은 상품을 다루면 같은 상품 페이지가 스토어 수만큼 생깁니다. 중복의 처리와, 브랜드와 기업의 관계를 전하는 Organization을 두는 방식은 구성에 따라 달라집니다.

구성	공통 상품의 중복 처리	Organization을 두는 방식
별도 도메인	각 도메인이 독립된 페이지로 색인된다. 내용이 같으면 어느 한쪽이 중복으로 제외될 가능성	각 도메인의 최상위에 각각의 브랜드를 Organization으로. 모회사와의 관계는 parentOrganization으로
서브도메인	동일 사이트 내 중복. canonical로 하나에 모은다	각 서브도메인의 최상위에 브랜드의 Organization. 메인 도메인의 최상위에 기업의 Organization
서브디렉터리	동일 사이트 내 중복. canonical로 하나에 모은다	메인 도메인의 최상위에 기업의 Organization. 각 브랜드는 Brand로 상품에 연결

중복 대처는 주가 되는 스토어를 정하고 다른 스토어의 공통 상품 페이지를 canonical로 주 스토어에 모으거나, 스토어마다 상품 설명을 다르게 써서 중복이 아니게 하는(운영 부하는 높다) 둘 중 하나이고, 공통 상품이 대부분이라면 애초에 스토어를 나누는 의미를 재검토합니다. W2의 멀티스토어 기능에서 공통 상품의 canonical이 어떻게 나오는지는 사양으로 확인합니다. 브랜드와 기업의 관계를 구조화 데이터로 밝혀 두면 AI 검색이 "이 브랜드는 이 기업 것"이라고 이해하고, 기업 질문에서 브랜드가, 브랜드 질문에서 기업이 함께 참조되기 쉬워집니다. 스토어를 추가할 때는 구성을 기존 스토어와 맞추고, Search Console 속성을 추가하고(도메인 속성이라면 서브도메인·서브디렉터리는 추가 불필요), 사이트맵을 등록하고, robots.txt를 확인하고(별도 도메인·서브도메인은 독립, 서브디렉터리는 공통), 공통 상품의 canonical과 Organization·Brand 구조화 데이터를 설정하고, 기업 최상위와 각 브랜드 사이에 내부 링크를 둡니다.

Search OS는 설정의 결과로 크롤러에 무슨 일이 생기는지 계속 지켜보는 층입니다

WAF 설정은 다음 변경에서 다시 무너지고, AI 크롤러는 새로운 것이 계속 나오므로 허용 목록의 전제도 바뀝니다. 여러 스토어에서는 템플릿 갱신, 상품 추가, canonical 설정처럼 한 스토어의 변경이 다른 스토어와 어긋나는 일이 일상이고, 스토어가 늘수록 "전 스토어에서 같은 방침이 지켜지는가"를 확인하는 부담이 커집니다. Search OS는 W2 같은 자사 운영 기반과 멀티스토어 구성을 떠받치는 층입니다. 봇 로그로 검색 엔진과 AI 크롤러의 응답 코드를 계속 감시하고, 차단 발생, 새로운 크롤러의 출현, 허용 목록과 실태의 어긋남을 찾아냅니다. 스토어를 가로질러 canonical·구조화 데이터·사이트맵·메타데이터가 서로 맞는지 확인하고, 공통 상품의 중복, Organization의 모순, 스토어별 봇 수집 차이를 수정 대상으로 정리합니다. WAF 설정을 하는 층도, 구성을 정하는 작업도 아닙니다.

담당자가 먼저 볼 질문

색인 수가 줄어든 주 전후에 WAF·봇 대책·속도 제한 설정을 바꾸지 않았는가. 바꾼 날짜는 기록되어 있는가
Search Console의 크롤 통계에서 403·429·5xx의 비율이 늘어난 시기가 있는가
주력 페이지의 URL 검사 실시간 테스트에서 가져올 수 있는가
허용 목록은 User-Agent만이 아니라 각사의 공개 IP 범위로 검증하고 있는가
AI 크롤러를 거부한다면 WAF가 아니라 robots.txt에 적혀 있는가
지명 검색의 유무, 고객층의 차이, 공통 상품의 많고 적음으로 별도 도메인·서브도메인·서브디렉터리 구성을 정했는가
공통 상품의 canonical은 주가 되는 스토어를 가리키고, 기업 최상위의 Organization에 각 브랜드가 연결되어 있는가

결론

W2 숍이 검색에 나오지 않을 때는 먼저 WAF·봇 대책의 설정 변경일과 Search Console의 크롤 통계를 맞춰 보고, 서버 로그에서 정규 크롤러에 대한 403·429를 찾습니다. 정규 크롤러는 IP로 검증해 허용 목록에 넣고, AI 크롤러의 처리는 방침으로 정해 거부는 robots.txt로 합니다. 멀티브랜드라면 브랜드의 독립성과 평가의 집약 중 무엇을 우선할지로 도메인 구성을 정하고, 공통 상품의 canonical과 Organization을 구성에 맞춰 설계합니다. 여기까지가 설정의 문제이고, 그 다음은 WAF 변경과 스토어 추가 때마다 같은 상태를 유지하는 운영의 문제입니다.

W2가 검색에 나오지 않을 때 먼저 볼 5가지