SEO 진단: 제가 사이트를 단계별로 진단하는 방법

SEO 진단은 사이트에서 무엇을 먼저 고칠지에 대한 결정이며, 권고마다 증거가 있고 실행 후 확인 방법이 있습니다. 도구가 주는 오류 목록은 진단의 재료일 뿐입니다. 테크니컬 SEO 진단은 그중에서 검색엔진과 AI 어시스턴트의 크롤러가 사이트를 가져와 읽을 수 있는지, 검색엔진이 색인할 수 있는지를 확인하는 부분입니다.

진단은 여덟 단계로 합니다.

1. 크롤러, 즉 검색엔진의 로봇처럼 사이트를 돌아다니는 프로그램을 돌리기 전에 목표와 사이트의 상황을 정합니다.
2. 크롤러가 애초에 페이지를 받는지 확인합니다.
3. 여러 출처에서 데이터를 모으고, 각 출처가 보지 못하는 것이 무엇인지 확인합니다.
4. 기술을 다루기 전에 키워드와 Google 검색 결과를 조사합니다.
5. 우선순위 조건이 붙은 문제 카탈로그에 따라 사이트를 점검합니다.
6. 항목마다 증거를 보여 줍니다.
7. 순서, 작업량, 대안을 정합니다.
8. 결과를 교차 검토에 맡기고, 실행 후 모든 항목을 다시 확인합니다.

SEO 진단이란 무엇이며 테크니컬 SEO 진단은 무엇이 다릅니까?

SEO 진단은 사이트가 어떤 상태이고 무엇이 가시성을 제한하는지 알려 주고, 테크니컬 SEO 진단은 검색엔진이 사이트를 가져오고, 렌더링하고, 색인할 수 있는지 확인합니다. 전체 진단에서는 페이지의 기술, 구조, 콘텐츠, 키워드, 외부 링크, 경쟁사를 점검하고 마지막에 작업 순서를 정합니다. 배포 후 하락, 사이트 이전, 색인에서 빠지는 페이지처럼 기술적인 문제를 다룰 때는 테크니컬 SEO 진단으로 충분합니다.

진단은 전략 수립의 근거이지 전략 자체가 아닙니다. 전략은 어떤 수요를 두고 경쟁할지와 무엇을 포기할지를 말하고, 진단은 지금 그것을 가로막는 것이 무엇인지 말합니다. 하나가 다른 하나로 이어지는 과정은 SEO 전략 글에서 설명했습니다.

SEO 진단은 단계별로 어떻게 합니까?

단계의 순서가 중요합니다. 앞 단계가 뒤 단계 숫자의 신뢰도를 결정하기 때문입니다. 저는 두 곳에서 프로세스를 멈추고 결정합니다. 첫 단계 뒤에 범위를 정하고, 교차 검토 뒤 고객에게 보내기 전에 우선순위와 주장을 확인합니다.

1단계. 크롤러를 돌리기 전에 목표와 사이트의 상황을 정합니다

첫 질문은 사이트가 트래픽을 잃고 있는지, 트래픽을 늘리지 못하고 있는지입니다. 진단 전체가 이 답에 달려 있기 때문입니다. 가시성이 없는 사이트는 먼저 키워드와 그에 답할 페이지의 지도가 필요합니다. 가시성이 있는 사이트는 누가 고치기 시작하기 전에, 이미 순위를 차지한 것부터 지켜야 합니다.

시작 전에 어떤 도구도 보여 주지 않는 것을 묻습니다. 어떤 제품이나 서비스가 수익을 내는지, 콘텐츠 관리 시스템 교체나 개편이 계획되어 있는지, 누가 권고를 실행하고 시간은 얼마나 있는지입니다. 답에서 진단의 범위와, 아무도 실행하지 않아서 풀어 쓰지 않을 것의 목록이 나옵니다.

이 단계는 직접 거쳐야 하는데, 지금은 많은 전문가가 언어 모델에 맡깁니다. 언어 모델은 도움이 될 수 있지만 고객의 비즈니스를 이해하지는 못합니다. 경험 있는 SEO 전문가가 가진 창의적이고 고유한 시각도 더하지 못합니다.

2단계. 크롤러가 애초에 페이지를 받는지 확인합니다

도구의 숫자를 읽기 전에 서버가 크롤러를 들여보내는지 확인합니다. 차단된 크롤러는 SEO 문제처럼 보이는 데이터를 주기 때문입니다. 2026년 7월 어느 한 주에 서로 다른 사이트 세 곳의 “SEO 문제” 세 가지가 모두 크롤러 차단이었습니다.

1. 한 사이트는 링크 분석 도구의 크롤러를 튕겨 내는 방화벽 뒤에 링크를 건 페이지들이 있어서 링크를 2,200개 넘게 “잃고” 있었습니다.
2. 한 쇼핑몰은 도구에서 사이트 헬스 점수가 0이고 오류가 거의 42,000개였는데, 도구의 크롤러가 페이지 대신 Cloudflare 방화벽의 응답을 받았기 때문입니다.
3. 세 번째 사이트에서는 차단이 크롤러를 첫 주소에서 멈추게 했고, 3주 동안 아무도 알아채지 못했습니다.

같은 주소를 일반 브라우저와 Google, Bing, OpenAI, Perplexity, Anthropic의 크롤러로 받은 뒤 응답 코드와 페이지 크기를 비교합니다. 브라우저와 크롤러의 차이는 무엇이든 세기 전에 먼저 설명해야 할 것입니다. 이런 테스트는 제 IP 주소에서 크롤러 이름으로 요청을 보내는데, 방화벽은 진짜 Google과 Bing 크롤러를 요청이 온 주소로 알아봅니다. 그래서 테스트에서 “Googlebot”이 차단된 것이 진짜 Googlebot의 차단을 증명하지는 않습니다. 사이트 소유자를 위한 Google의 무료 패널인 Search Console은 진짜 Googlebot이 사이트를 어떻게 보는지 보여 줍니다.

robots.txt 파일은 눈이 아니라 파서, 즉 크롤러처럼 규칙을 적용하는 프로그램으로 끝까지 읽습니다. Google 크롤러는 규칙 그룹을 하나만 적용하는데, 크롤러 이름과 가장 잘 맞는 그룹이고 나머지는 건너뜁니다. 경로 없는 Disallow: 규칙은 아무것도 차단하지 않습니다(Google Search Central). 2026년 8월에 어느 사이트의 robots.txt 일부를 보면 Google을 차단하는 것처럼 보였습니다. 파서는 Googlebot에게 전체 접근이 있고 Bing과 AI 어시스턴트의 크롤러가 차단되어 있음을 보여 주었습니다. 진단이 달라진 것입니다. 문제는 Google이 아니라 Bing과 AI 크롤러에 있었습니다.

robots.txt 파일이 없다고 Google이 막히지는 않지만, 배포할 때마다 파일이 사라지지 않았는지 확인합니다. Google은 robots.txt의 4xx 오류(429 제외)를 파일이 없는 것처럼, 즉 제한이 없는 것으로 취급합니다(Google Search Central). 제 사이트는 2026년 8월에 제가 고치기 전까지 robots.txt에 404 오류를 돌려주고 있었습니다.

3단계. 여러 출처의 데이터를 모으고, 각 출처가 보지 못하는 것을 확인합니다

크롤러의 모든 숫자는 두 번째 출처가 확인해 주기 전까지 가설입니다. JavaScript를 실행한 크롤과 실행하지 않은 크롤, 그리고 CrUX 보고서의 실제 사용자 속도 데이터를 모읍니다. 여기에 링크 프로필과 측정일의 중요 키워드 검색 결과를 더합니다. 캠페인 계획 전에 링크 프로필을 어떻게 확인하는지는 링크 빌딩 글에서 설명했습니다. 파일마다 출처, 날짜, 범위를 적어 두어서 한 달 뒤에도 모든 숫자를 재현할 수 있게 합니다.

Search Console 데이터는 API, 즉 데이터를 자동으로 가져오는 인터페이스로 가져옵니다. 패널의 내보내기는 목록을 1,000행에서 자르기 때문입니다. API는 결과 유형마다, 예를 들어 웹 페이지, 이미지, 동영상을 따로 하루 최대 50,000행을 돌려줍니다(Google, Search Console 도움말). 잘린 내보내기가 한 사이트의 CTR을 부풀린 사례는 SEO를 위한 AI 도구 글에서 보여 드렸습니다.

크롤러는 사이트의 규모를 실제보다 작게 잡을 수 있으므로, 페이지와 제품의 수는 두 번째 출처로 확인합니다. 쇼핑몰 두 곳에서 크롤러는 카테고리의 제품 목록 첫 페이지까지만 가고 더 가지 않았습니다. 다음 목록 페이지들은 작동했고 차단되지도 않았는데도 그랬습니다. 한 쇼핑몰에서는 제품의 절반도 찾지 못했고, 다른 곳에서는 3분의 1도 찾지 못했습니다. 이 숫자를 쇼핑몰의 상태로 제시했다면, 진단은 실제로는 없는 상품 구성의 빈틈을 설명하게 되었을 것입니다.

일별 데이터의 갑작스러운 변화는 원인을 붙이기 전에 먼저 기술합니다. 클릭, 노출, 순위, 세션, Google 크롤러의 요청에 대해 합니다. 연속 7일의 중앙값이 그 직전 14일의 중앙값과 25% 이상 다른 날을 찾습니다. 그런 날짜마다 배포, Google 업데이트, 장애, 측정 변경, 또는 “원인 불명”이라는 설명을 적습니다. 각 날짜에 대한 기록을 바탕으로 가설을 세우고, 다른 가능한 설명을 확인한 뒤에야 원인을 지목합니다.

4단계. 기술보다 먼저 키워드와 Google 검색 결과를 봅니다

먼저 기회를 찾고, 그다음 오류를 고칩니다. 일부 기술 문제는 키워드에 비추어야만 평가할 수 있습니다. 쇼핑몰의 필터를 색인해야 하는지, 태그가 별도 페이지를 가질 자격이 있는지, 두 페이지가 정말 같은 것을 두고 경쟁하는지입니다. 카탈로그에서는 32개 문제 유형이 키워드와 Google 검색 결과의 분석 없이는 평가할 수 없다고 표시되어 있습니다.

중요한 키워드에 맞는 페이지가 없는 것은 제 진단에서 비교적 흔한 문제로, 63건 중 15건, 사이트 50개 중 14개에서 나왔습니다. 크롤러는 존재하는 페이지만 가져오므로 이것을 스스로 보고하지 못합니다. 수요를 주소 목록과, 검색 결과에 나타나는 경쟁사 페이지와 대조해야만 보입니다.

5단계. 우선순위 조건이 붙은 카탈로그에 따라 점검합니다

같은 오류도 어디에서 나타나느냐에 따라 우선순위가 높거나 낮습니다. 수천 개 페이지에 반복되는 템플릿에서 리디렉션 주소로 가는 내부 링크는 우선순위가 높습니다. 한 게시물 본문의 같은 링크는 중간이고, 오래된 게시물에서는 낮습니다.

카탈로그의 문제 유형마다 탐지 규칙, 보고 조건, 필요한 증거, 조건이 붙은 우선순위, 실행 후 확인 방법이 있습니다. 256개 유형 중 86개는 우선순위 규칙을 “높음”으로 시작하지만, 거의 항상 조건이 붙습니다. 키워드에 수요가 있을 때, 페이지에 트래픽이 있을 때, 오류가 템플릿에 있을 때입니다.

그래서 도구의 사이트 헬스 점수는 우선순위를 정하지 않습니다. 도구는 오류를 세지, 그 오류에 달린 트래픽을 세지 않습니다. 트래픽을 모르는 페이지에 대한 권고는 데이터를 확인하기 전까지 높은 우선순위를 받지 못합니다.

6단계. 항목마다 증거를 보여 줍니다

증거가 없는 항목은 권고가 아니라 “확인 필요”로 진단에 남습니다. 증거는 코드 위치의 스크린샷이거나, JavaScript 실행 후 버전 옆에 놓은 서버의 HTML입니다. Search Console의 차트나, 속도를 해치는 요소의 이름이 붙은 속도 측정일 수도 있습니다. 로딩을 해치거나 레이아웃을 움직이는 요소는 제 가설에 맞는 이름이 아니라 측정이 가리키는 이름으로 부릅니다.

각 항목은 문제에서 수정 확인까지 네 부분으로 설명합니다. 문제가 무엇인지, 왜 해로운지와 무엇에 영향을 주는지, 단계별로 어떻게 고치는지, 수정이 통했는지 어떻게 확인할지를 씁니다. 고칠 코드는 개발자가 바꿀 정확한 지점을 볼 수 있도록 사이트에서 그대로 복사합니다.

리디렉션으로 가는 링크에 대한 보고 하나는 요약하면 이렇습니다.

• 문제: 메뉴의 링크가 끝에 슬래시가 없는 주소로 가고, 이 주소가 슬래시가 있는 버전으로 리디렉션됩니다.
• 왜 해로운가: 메뉴는 모든 페이지에 있으므로 모든 클릭과 크롤러의 모든 요청이 추가 리디렉션을 거칩니다. 도구의 보고서에서는 이런 링크 수천 개가 더 중요한 오류를 찾기 어렵게 만듭니다.
• 수정: 메뉴 템플릿에서 주소를 최종 주소로 바꾸고, 변경 전후의 코드 조각을 첨부합니다.
• 확인: 배포 후 크롤에서 템플릿에 리디렉션 주소로 가는 링크가 나타나지 않습니다.

7단계. 순서, 작업량, 대안을 정합니다

진단의 결과는 발견 사항의 수가 아니라 순서입니다. 문서 맨 앞에는 모든 항목의 우선순위와 작업량을 담은 표가 있습니다. 작업량은 몇 시간, 하루나 이틀, 일주일, 프로젝트 전체의 네 단계로 적습니다. 여력이 적은 팀에는 전체 방안과 함께 최소 방안을 제시하고, 더 짧은 길을 택하면 무엇을 잃는지 분명히 적습니다.

실행은 진단을 그대로 따릅니다. 실행 견적에서 더 저렴한 대안이 나오면 고객이 선택하고 저는 그것을 그대로 기록하며, 고객이 모르게 권고를 바꾸지 않습니다.

8단계. 교차 검토와 실행 후 확인

진단이 고객에게 가기 전에, 쓰지 않은 사람이 검토합니다. 검토는 두 번 합니다. 첫 번째는 문서 전체에, 두 번째는 첫 검토 뒤에 바뀐 것에만 합니다. 검토는 숫자를 처음부터 다시 계산하고, 증거로 방어할 수 없는 주장을 찾습니다. 마지막으로 고객의 상황에 달린 우선순위와 주장을 제가 직접 확인합니다.

실행 후에는 작동하는 사이트에서 모든 항목을 확인하고 제대로 실행됨, 일부 실행됨, 실행 안 됨으로 표시합니다. 이 확인은 진단 가격에 포함됩니다. 이 단계가 없으면 진단은 문서에서 끝나고 사이트의 변화로 이어지지 않습니다.

테크니컬 SEO 진단에서는 무엇을 확인합니까?

테크니컬 SEO 진단에서는 십수 개 영역을 점검하고, 문제는 리디렉션, 사이트 구조, 콘텐츠에서 가장 자주 보고합니다. 마지막 열은 아카이브의 진단 63건 중 몇 건에서 작성자가 해당 영역의 문제를 하나 이상 보고했는지 보여 줍니다. “확인하는 것” 열은 영역 전체가 아니라 예시입니다. 표는 선택한 영역만 보여 주며, 카탈로그는 문제를 22개 영역으로 나눕니다.

드물게 보고되는 문제가 드물게 나타나는 문제라는 뜻은 아닙니다. 속도와 JavaScript는 이 표에서 보고 건수가 적지만, 아카이브의 진단들은 범위가 서로 달랐습니다. 그래서 보고 건수가 적다고 해서 이런 문제가 사이트에 얼마나 자주 나타나는지 알 수는 없습니다.

사이트의 색인은 어떻게 확인합니까?

색인은 세 목록으로 확인합니다. 사이트맵에 있는 것, Google이 색인한 것, 크롤러가 링크로 찾는 것입니다. 이 세 목록의 불일치는 각각 따로 볼 때보다 문제를 더 잘 보여 줍니다. 리디렉션, 오류를 돌려주거나 색인에서 제외된 주소가 들어 있는 사이트맵은 진단 63건 중 20건, 사이트 50개 중 18개에서 보고되었습니다. 개별 주소에는 Search Console의 URL 검사를 쓰는데, JavaScript 실행 후의 페이지도 보여 줍니다.

Core Web Vitals는 순위에 영향을 줍니까?

Core Web Vitals는 Google 랭킹 시스템의 일부이지만, 콘텐츠의 관련성을 이기지는 못합니다. Google은 랭킹 시스템이 Core Web Vitals를 활용한다고 분명히 씁니다. 또 페이지 경험이 좋지 않아도 항상 가장 관련성 높은 콘텐츠를 보여 주려 한다고 씁니다(Google Search Central). 진단에서는 실험실 도구의 한 번 테스트가 아니라 CrUX 보고서의 실제 사용자 데이터를 씁니다. Google이 페이지 유형별로 그런 데이터를 가진 곳에서는 유형별로 따로 제시합니다. 이 데이터가 없는 경우는 진단에 적습니다. 2024년 3월 12일부터 페이지의 반응을 재는 지표는 INP이고, FID를 대체했습니다(web.dev).

SEO 진단에서 가장 자주 찾는 오류는 무엇입니까?

가장 자주 반복되는 것은 기본적인 관리 오류, 즉 도구가 쉽게 찾아내는 것들입니다. 리디렉션과 404 오류로 가는 링크, 잘못된 주소가 들어간 사이트맵, 중복된 페이지 제목과 설명입니다. 리디렉션 주소로 가는 내부 링크는 진단 63건 중 24건, 사이트 50개 중 20개에서 나타났습니다. 도구는 이를 잘 찾아내고, 수정 비용은 템플릿과 사이트 시스템에 달려 있습니다.

드물게 보고되는 구조 문제가 기본적인 관리 오류보다 트래픽에 더 큰 영향을 줄 수 있습니다. 중요한 키워드용 페이지가 없는 것은 진단 63건 중 15건에서 보고되었고, 블로그가 서비스와 카테고리 페이지로 링크하지 않는 문제도 15건에서 보고되었습니다. 카탈로그는 키워드에 수요가 있고 경쟁사가 별도 페이지로 순위를 차지하고 있을 때 빠진 페이지에 높은 우선순위를 줍니다. 링크 없는 블로그는 도착 페이지에 트래픽이나 수익이 있고 블로그에 권위가 있을 때 높은 우선순위를 받습니다. 우선순위를 주기 전에 이 조건을 데이터로 확인합니다.

• 938진단 63건, 사이트 50개의 발견 사항 수이며, 여기서 문제 유형 256개의 카탈로그를 만들었습니다2020-2026년 진단 아카이브, 2026년 10월 11일의 카탈로그
• 38%리디렉션 주소로 가는 내부 링크가 있는 진단의 비율로, 아카이브에서 가장 자주 보고된 문제입니다(63건 중 24건)2026년 10월 11일의 카탈로그
• 15건 / 63건중요한 키워드용 페이지가 없는 진단으로, 크롤러가 스스로 보고하지 못합니다2026년 10월 11일의 카탈로그
• 14카탈로그가 현재 낡았다고 표시하는 권고의 유형 수이고, 30개는 바뀐 관행으로 표시합니다2026년 10월 11일의 카탈로그

2020년 이후 SEO 진단은 무엇이 달라졌습니까?

2023-2026년의 진단에서는 구조화 데이터와 페이지네이션이 2020-2022년보다 더 자주 나오고, 리디렉션, 표준 주소, 색인은 덜 나옵니다. 구조화 데이터 문제는 최근 진단 33건 중 23건에서, 이전 진단 30건 중 16건에서 보고되었습니다. 리디렉션과 응답 코드는 33건 중 23건 대 30건 중 27건입니다. AI 크롤러 차단은 2026년의 진단에서야 나타납니다. 진단의 연도는 아카이브 파일의 날짜이므로 작업을 한 해와 늘 같지는 않습니다.

감소가 리디렉션 문제가 사라졌다는 증거는 아닙니다. 진단의 구성이 달라졌고, 최근 진단은 구조화 데이터, 콘텐츠, AI 가시성을 더 자주 다루었으며 작업 방식도 달라졌습니다. 이 차트가 보여 주는 것은 진단이 무엇을 다뤘는지이지, 폴란드 사이트가 어떻게 달라졌는지가 아닙니다.

지금은 어떤 SEO 권고가 낡았습니까?

일부 권고는 지금도 진단과 가이드에 나오지만, 오늘날에는 적용할 가치가 없습니다. 그중 일부는 몇 년 전에는 통했고, 일부는 Google이 오래전부터 권하지 않거나 무시했습니다. 표에서는 관행마다 이유와 그 대신 할 일을 적습니다.

표의 출처: Google의 페이지네이션 문서, Google의 rel=canonical 다섯 가지 실수, Google의 FAQ와 HowTo 결과, Matt Cutts의 nofollow와 링크 힘 분배, John Mueller의 홈페이지 리디렉션, Search Engine Roundtable 인용, Google의 robots.txt, Google의 robots.txt에서 지원하지 않는 규칙, Google의 사이트맵, Google의 lastmod, changefreq, priority 필드, web.dev의 INP, Google의 검색 결과 검색창.

그래서 제 카탈로그의 모든 권고에는 근거가 붙은 최신성 항목이 있습니다. 카탈로그는 현재 권고 14개 유형을 낡은 것으로, 30개를 바뀐 관행으로 표시합니다. 몇 년 전에는 맞았던 권고라도, 한때 통했다는 이유만으로 진단에 들어가지 않습니다.

진단에서 AI 크롤러의 접근은 어떻게 확인합니까?

AI 크롤러의 접근은 Googlebot의 접근과 같은 단계에서 확인합니다. 같은 방화벽이나 CDN 설정이 둘을 모두 막을 수 있기 때문입니다. CDN은 Cloudflare 같은 중개 서버 네트워크입니다. 2026년 9월에 Cloudflare 뒤에서 운영되는 고객 도메인 12개를 확인했습니다. robots.txt 파일만으로는 이렇게 나왔습니다.

• 도메인 3개는 모델 학습용 데이터를 수집하는 크롤러 일곱 개를 같은 목록, 같은 이름으로 차단하고 있었습니다. 같은 목록은 공통의 출처, 예를 들어 Cloudflare 패널의 기본 설정을 시사합니다. 이 설정은 밖에서는 보이지 않으므로 패널에서 직접 확인해야 합니다.
• 도메인 1개는 ChatGPT, Perplexity, Claude의 답변을 위해 페이지를 가져오는 크롤러를 차단하고 있었습니다. 이름을 직접 지정해서가 아니라, 이름이 없는 모든 크롤러에 적용되는 일반 규칙으로 막았습니다. 같은 도메인은 GPTBot에게 페이지를 색인에서 제외하는 noindex 태그가 없는 보안 페이지를 보여 주었습니다. 색인용 크롤러가 이런 페이지를 받았다면 색인에 콘텐츠 대신 차단 페이지가 들어갈 수 있었습니다.
• 도메인 8개는 robots.txt에 차단이 없었습니다.

답변을 위해 페이지를 가져오는 크롤러와 학습용 데이터를 수집하는 크롤러는 따로 결정합니다. 이를 구별하는 방법은 GEO 최적화와 AI SEO 글에서 설명했습니다. 2026년 8월 31일부터는 Search Console에 AI Overview, AI 모드, Discover의 생성형 기능에서 사이트를 제외하는 별도의 설정도 있습니다. Google에 따르면 이 설정은 나머지 검색 결과에 영향을 주지 않습니다(Search Console 도움말). SEO 담당자가 모르는 사이에 누군가 켰을 수 있으므로, 이 설정도 진단에서 robots.txt와 똑같이 확인합니다. 접근을 연 뒤 브랜드가 답변에 나타나는지는 별도의 측정이며, 브랜드의 AI 가시성 글에서 설명했습니다.

IP 주소 하나에서 하는 테스트는 상황의 일부만 보여 주고, 스스로 오경보를 낼 수 있습니다. 같은 점검에서 요청 시리즈가 도메인 두 곳에서 한도 초과 후의 차단을 보고했습니다. 그 차단은 제 앞선 요청이 일으킨 것이었습니다. 몇 분 뒤 크롤러 식별자 하나와 개별 요청으로 다시 확인하자 연속으로 정상 응답이 다섯 번, 일곱 번 나왔습니다. 이 확인이 없었다면 고객 두 곳은 없었던 차단에 대한 정보를 받았을 것입니다. ChatGPT가 실제로 페이지를 가져오는지는 서버 로그에서만 보입니다. llms.txt 파일 글에서는 제 사이트의 로그에서 보이는 것을 보여 드립니다.

응답 코드 200이 크롤러가 콘텐츠를 받았다는 뜻은 아닙니다. JavaScript 애플리케이션을 쓰는 한 고객에서 Googlebot과 Bingbot은 프리렌더 서비스에서 완성된 HTML을 받았고, AI 어시스턴트의 크롤러는 빈 페이지를 받았습니다. 서비스가 크롤러를 이름으로 알아보는데 AI 크롤러가 목록에 없었습니다. 제 테스트는 콘텐츠가 아니라 응답 코드를 측정했기 때문에 “정상”이라고 나왔습니다. 그 뒤로 크롤러가 받는 콘텐츠를 브라우저에서 JavaScript를 실행한 뒤의 콘텐츠와 비교합니다.

무료 SEO 진단으로 충분합니까?

무료 도구는 오류 목록을 보여 주지만, 보고서만으로는 어떤 오류가 트래픽을 잃게 하는지 알 수 없습니다. 폴란드어 검색어 “audyt seo”에서는 Google 첫 페이지의 자연 검색 결과 9개 중 7개가 도구이거나 무료 진단 제안입니다(2026년 10월 17일의 결과). 그런 보고서는 도구의 규칙으로 오류를 세지, 그 오류에 얼마나 많은 트래픽과 수익이 달려 있는지로 세지 않습니다. 헬스 점수가 0이던 쇼핑몰의 경우처럼, 결과가 크롤러 차단에서 나온 것이 아닌지도 확인해야 합니다.

어디를 봐야 하는지 알면 무료로도 많은 것을 할 수 있습니다. Search Console은 색인, Core Web Vitals, JavaScript 실행 후의 페이지에 대한 Google의 데이터를 보여 줍니다. Screaming Frog 무료 버전은 한 번의 크롤에서 500개 주소까지 돌아다니므로(Screaming Frog) 작은 회사 사이트에는 충분합니다. 컨설턴트와 하는 진단은 오류의 비용이 클 때(이전, 트래픽 하락, 큰 쇼핑몰)나 데이터를 모아 평가할 시간이 없을 때 의미가 있습니다.

ChatGPT가 SEO 진단을 해 줍니까?

ChatGPT나 다른 AI 모델은 검색엔진의 크롤러처럼 페이지를 보지 못하므로 혼자서 전체 진단을 하지 못합니다. 보통은 페이지를 가져와서 텍스트로 바꿔 주는 도구를 통해 봅니다. 모델은 귀하가 주는 데이터를 읽고 무엇을 확인할지 제안할 수 있습니다. 하지만 가져오기 도구가 페이지의 일부를 잃을 수 있습니다. 2026년 9월에 Claude Code의 페이지 가져오기 도구가 페이지를 텍스트로 바꾸면서 구조화 데이터를 잘라 낸다는 것을 확인했습니다. 모델은 같은 페이지의 마크업에 있었는데도 정보가 없다고 답했습니다. 이렇게 한 진단은 실제로 존재하는 구조화 데이터가 없다고 보고했을 것입니다. 제 프로세스에서 AI는 도구이며, 주로 크롤, Search Console, 다른 출처의 데이터를 모으는 데 씁니다. 범위, 평가, 우선순위는 제가 직접 정합니다.

SEO 진단은 비용이 얼마입니까?

진단은 컨설팅과 같은 방식으로 정산합니다. 시간당 70 EUR(부가세 별도)이고, 시작 전에 시간의 상한을 정합니다. 시간은 무엇을 확인해야 하는지에 따라 달라집니다.

• 진단형 점검, 즉 하나나 두 개의 구체적인 문제(하락, 이전, 색인)는 보통 10-16시간이고, 700-1,120 EUR(부가세 별도)입니다.
• 작업 순서가 포함된 전체 진단은 보통 32-50시간이고, 2,240-3,500 EUR(부가세 별도)입니다.
• 500개 주소까지의 작은 사이트는 하한에 가깝고, 주소가 수천 개이고 필터가 있는 쇼핑몰은 상한에 가깝습니다.
• 언어 버전은 보통 3-5시간을 더하고, 진단해야 하는 진행 중인 위기는 4-8시간을 더합니다.

가격에는 분석, 권고가 담긴 보고서, 이를 논의하는 미팅, 실행 후 확인이 들어 있습니다. 실행 자체는 귀하의 팀이 하거나 제가 따로 견적을 냅니다.

Search Console, CDN 패널, 호스팅에 대한 접근이 없으면 기술 부분을 완전히 확인할 수 없고, 견적 전에 그렇게 말씀드립니다. 그 접근 없이는 무엇을 확인하지 못하는지 알려 드리고 그에 맞춰 범위를 줄입니다. 진단 대신 결정 하나에 대한 대화로 충분한 경우는 SEO 컨설팅 글에서 설명했습니다.

SEO 진단에 대해 자주 묻는 질문

어디서 시작하면 됩니까?

질문 하나로 시작하십시오. 사이트가 트래픽을 잃고 있는지, 트래픽을 늘리지 못하고 있는지입니다. 이 답에 따라 순위가 있는 페이지부터 지킬지, 페이지가 없는 키워드를 찾을지가 정해집니다. 그다음 직접 하는 방법의 답에 나온 무료 점검 세 가지를 하십시오. robots.txt, Search Console의 색인 보고서, Screaming Frog 무료 버전의 크롤입니다. 결과가 뜻밖이거나 무엇부터 고칠지 모르겠다면 컨설팅의 좋은 주제입니다.