아티클

기술 SEO 감사란 구체적으로 무엇인가

Screaming Frog 자동 리포트는 감사가 아니에요. 기술 SEO 감사에 실제로 뭐가 들어가고 뭐가 빠지는지, 돈을 내기 전에 그 차이를 알아보는 법이에요.

2026년 9월 6일기술 SEO · 감사 · 웹 개발

‘SEO 감사를 한 번 받아 봤는데 아무것도 안 바뀌었어요.’ 이 서비스에 이미 한 번 돈을 써 본 클라이언트에게서 가장 자주 듣는 말 중 하나예요. 기술 SEO가 작동하지 않아서가 아니라, 받은 게 감사가 아니었기 때문일 가능성이 거의 확실해요. 진단 단계에서 멈춘 보고서였고, 거기서 아무도 아무것도 구현하지 않았으니 어떤 지표도 움직이지 않은 거예요.

문제는 정의에서 시작해요. 루마니아 시장에서 별도로 값을 치르고 사는 ’SEO 감사’는 오히려 예외에 가까워요. 에이전시는 거의 예외 없이 SEO를 월 구독으로 팔아요. 콘텐츠, 링크 빌딩, 온페이지, 리포팅을 한 덩어리로 녹인 패키지이고, 중소기업은 월 300~~1,500유로, 중대형 이커머스나 경쟁이 심한 니치는 월 1,500유로에서 5,000유로 이상이에요. 별도 산출물로서의 단독 감사는 작은 에이전시에서 200~~1,000유로, 시장에 공개된 자료를 보면 사이트 규모에 따라 2,499레이에서 3만 9,999레이 사이예요.

사실상 자동 리포트인 감사는 어떻게 생겼나

시장에서 가장 흔하고, 무엇을 봐야 하는지 알면 가장 쉽게 알아볼 수 있는 첫 번째 실수예요. 맞춤 분석처럼 포장했지만 실제로는 Semrush나 Screaming Frog 같은 도구에서 뽑은 자동 리포트인 ’SEO 감사’를 사는 거예요. 1,000레이 미만이면 거의 확실히 이걸 받아요. 이런 보고서는 오류, 끊어진 링크, 중복 제목, 메타 설명이 없는 페이지를 나열하지만, 그걸 해당 사이트의 실제 비즈니스 목표에 비추어 해석하지는 않아요.

두 번째 실수는 첫 번째와 이어져요. 찾아낸 문제를 모두 똑같이 급한 것으로 다루는 거예요. 쓸모 있는 감사는 비즈니스 임팩트로 우선순위를 매기지, 전부를 똑같이 늘어놓지 않아요. 개발 예산이 한정되어 있다면 먼저 색인을 막는 것부터 풀어야지, 겉모습에 관한 것부터 손대면 안 돼요. 세 번째이자 장기적으로 가장 비싼 실수는, 감사를 PDF 권고 목록으로 넘기고 그게 거기에 그대로 남는 거예요. 구현 없는 진단은 어떤 지표도 움직이지 않아요. 결과가 아니라 보고서에 돈을 쓴 셈이에요.

실제로 들어가야 하는 것

기술 SEO는 감이 아니라 Google이 페이지를 발견하고 처리하고 보여주는 구체적인 방식에 기반해요. Google Search Central이 명시적으로 문서화해 두었어요. 단계는 셋으로 나뉘어요. 크롤링에서는 Googlebot이 URL을 요청하고 robots.txt를 확인해요. 렌더링에서는 상태 코드 200인 페이지가 헤드리스 Chromium 렌더링 큐에 들어가요(여기서 JavaScript가 실행돼요). 색인에서는 Google이 이미 렌더링된 HTML을 써요. 어느 단계의 오류든 사슬 전체를 막아요. robots.txt에서 막힌 페이지는 콘텐츠가 아무리 좋아도 절대 색인에 닿지 못해요.

그래서 진짜 감사는 크롤 가능성(robots.txt, 내부 링크, 대형 사이트라면 로그 파일), 사이트맵이 선언한 것과 비교한 실제 색인 상태, 그리고 최신 프레임워크(React, Vue, Next.js)에서의 JavaScript 렌더링을 확인해요. 브라우저에서만 생성되는 콘텐츠는 색인되기 전에 Googlebot이 렌더링해야 하고, 이게 지연과 위험을 더해요. 또 기존 구조화 데이터와 새로운 기회, 속도와 Core Web Vitals, 정규화와 중복 콘텐츠, 다국어 사이트의 hreflang 설정을 확인해요.

구조화 데이터는 따로 언급할 만해요. Google이 임팩트를 직접 문서화했거든요. Rotten Tomatoes는 구조화 데이터가 있는 페이지에서 CTR이 25% 높다고 보고했고, Nestlé는 82% 높았으며, Food Network는 페이지의 80%를 전환한 뒤 방문이 35% 늘었어요. 엄격한 규칙은 사용자에게 보이지 않는 정보를 마크업하지 않는다는 것이고, 검증은 Rich Results Test와 Search Console로 해요. 정직하게 짚을 점도 있어요. 기술적으로 올바른 구조화 데이터가 리치 결과를 자동으로 보장하지는 않아요. 콘텐츠 품질을 근거로 표시 여부와 시점은 Google이 정해요.

매일 갱신되는 페이지가 1만 개를 넘거나 매주 갱신되는 페이지가 100만 개를 넘는 대형 카탈로그에서는 크롤 예산이 의미를 가져요. 서버가 감당하는 트래픽과 콘텐츠 갱신의 빈도, 품질이 이를 좌우해요. 나머지 사이트에는 최신 상태의 사이트맵이면 충분해요. 리디렉션에서는 차이가 중요해요. 301과 308은 정규화 신호를 넘기고 302와 307은 넘기지 않으며, 리디렉션 체인은 크롤 예산을 헛되이 낭비해요.

Core Web Vitals는 여전히 구체적인 세 지표예요. LCP 2.5초 미만, INP 200밀리초 미만, CLS 0.1 미만이에요. Google은 이것이 ’우리 랭킹 시스템이 보상하려는 바와 맞닿아 있다’고 확인하면서도, 콘텐츠 관련성 대비 가중치를 공개적으로 수치화하지는 않아요. 그래도 여러 요인 중 하나라는 건 여전히 의미가 있고, 전환에 미치는 직접적인 영향과 합치면 더 그래요.

기술 SEO에 들어가지 않는 것

이 구분은 형식적인 게 아니에요. 키워드 리서치, 콘텐츠 전략, 본문의 온페이지 최적화, 링크 빌딩, 로컬 SEO는 기술 SEO가 아니라 콘텐츠 SEO에 속해요. 콘텐츠 전략은 무엇에 대해 어떤 검색 의도로 쓸지 정하고, 기술 SEO는 Google이 그 콘텐츠에 닿을 수 있는지, 제대로 이해할 수 있는지, 결과에 보기 좋게 띄울 수 있는지를 정해요. 콘텐츠는 훌륭한데 색인 오류가 있는 사이트는, 콘텐츠는 약한데 기술은 완벽한 사이트만큼 트래픽을 잃어요. 다만 전문성이 없는 사람에게는 문제를 진단하기가 더 어려울 뿐이에요.

정직하게 다룰 만한 논점이 하나 더 있어요. AI가 만든 결과가 늘어난 지금도 SEO가 의미가 있느냐는 거예요. 2025년 Pew Research가 미국 성인 900명의 Google 검색 약 6만 9,000건을 대상으로 한 연구를 보면, 응답자의 58%가 AI 요약이 뜬 검색을 최소 한 번 경험했어요. 그런 요약이 뜨면 사용자가 전통적인 오가닉 링크를 클릭하는 비율은 방문의 8%에 그쳐요. 요약이 없을 때의 15%와 비교하면 사실상 절반이에요. 실무적 결론은 단순해요. Google이 당신의 페이지를 색인하거나 제대로 이해하지 못하면, 고전적인 결과에도 AI Overviews의 인용에도 자격이 없어요. 시장 전체로 보면 오가닉 클릭의 총량이 압박을 받고 있더라도, 기술적 토대는 둘 모두의 기본 조건으로 남아요.

수정은 누가 해야 하나

특히 내부 개발 팀이 이미 있다면 나올 법한 질문이에요. 왜 우리 개발자가 하면 안 되나요? 할 수 있어요. 다만 그 특정 전문성이 함께 있어야 해요. Googlebot이 어떻게 렌더링하는지, 크롤 예산이 무엇인지, 정규화가 규모에서 어떻게 움직이는지 같은, 일반적인 개발과는 다른 니치 역량이에요. 좋은 개발자는 기능적으로 올바른 코드를 쓰지만, 크롤러의 동작을 세세히 알 이유는 별로 없어요. 매일의 업무가 아니니까요.

개발과 분리해서 산 기술 감사의 가장 큰 한계는 정확히 이 둘 사이의 인수인계예요. 에이전시는 PDF 보고서를 넘기고, 그걸 구현해야 할 개발자는 진단에 참여하지 않았으며, 다른 우선순위로 이미 꽉 찬 백로그에 ’SEO 작업’을 위한 시간이 배정되어 있지 않은 경우가 많아요. 기술 권고안은 몇 달씩 그대로 남아요. 악의 때문이 아니라, 진단과 구현 역량을 동시에 가진 사람이 없기 때문이에요. 그래서 지표를 움직이는 감사와 문서로 남는 감사의 실제 차이는 진단의 품질 자체가 아니라 다음 걸음을 누가 딛느냐에 있어요.

개발이 계속되면서 회귀가 꾸준히 생기는 대형 사이트에서는 감사와 구현 한 번으로는 충분하지 않아요. Search Console의 월간 점검, 이미 적용한 구조화 데이터의 주기적 검증, 릴리스마다 새로 생긴 문제에 대한 알림이 기술적 토대를 장기적으로 안정시켜요. 최초 개입 직후에만이 아니고요.

실제 회복은 어떻게 생겼나

기술 감사는 사이트 규모에 따라 1주에서 3주가 걸려요. 기술 문제가 심한 사이트에서는 수정의 효과가 보통 구현 후 4~8주에 보이고, 사이트맵에서 실제로 색인된 페이지의 추이와 Search Console의 ‘발견됨, 색인 생성 안 됨’ 감소로 추적해요. 진지한 사람이라면 아무도 보장된 성장 수치를 약속할 수 없지만, 무언가를 바꾸는 감사와 PDF로 남는 감사의 차이는 시장의 대다수 제안이 빼놓는 바로 그 단계에 있어요. 찾아낸 문제를 누가 고치느냐예요. 임팩트로 우선순위를 매긴 감사와 코드에 직접 반영하는 구현이 어떤 모습인지 보고 싶으시다면, 기술 SEO 페이지에서 그 과정을 더 읽어 보실 수 있어요.

출처

비슷한 상황이신가요?

지금 어느 지점에 계신지 알려주세요. 여기서 읽으신 것과 다른 답이 맞다면 그렇게 말씀드려요.

견적 요청하기