사이트 속도·성능은 SEO·GEO 노출에 영향을 줄까? 구글·네이버·AI 검색 기준 정리

사이트가 느리면 검색에서 불리할까요? 홈페이지 리뉴얼이나 서버 이전을 앞두고 자주 나오는 질문입니다. 결론부터 말하면 영향은 있습니다. 다만 순위를 직접 끌어올리는 힘보다, 검색엔진과 AI가 페이지를 가져가고 읽는 단계에서 더 크게 작용합니다. 구글, 네이버, AI 검색 서비스가 공개한 문서를 기준으로 확인된 사실과 확인되지 않은 부분을 나눠 봤습니다.

구글 검색에서 속도는 순위 신호이지만 관련성이 먼저입니다

구글은 페이지 경험 안내 문서에서 코어 웹 바이탈이 순위 시스템에 쓰인다고 밝혔습니다. 동시에 페이지 경험을 판단하는 단일 신호는 없고, 페이지 경험이 좋지 않더라도 가장 관련성 높은 콘텐츠를 보여 준다고 설명합니다. 검색어에 맞는 좋은 페이지가 여럿일 때 페이지 경험이 순위를 가르는 요소가 된다는 뜻입니다.

코어 웹 바이탈은 세 가지 지표로 이뤄집니다. LCP는 화면에서 가장 큰 콘텐츠가 보이기까지 걸리는 시간, INP는 클릭이나 입력에 화면이 반응하기까지 걸리는 시간, CLS는 로딩 중에 화면 요소가 밀려나는 정도입니다. 구글의 웹 성능 가이드는 LCP 2.5초 이하, INP 200밀리초 이하, CLS 0.1 이하를 좋은 수준으로 봅니다.

기준은 실제 방문자 데이터로 판단합니다. 크롬 사용자 경험 보고서(CrUX)가 실제 방문자의 측정값을 모으고, 모바일과 데스크톱을 나눠 방문의 75%가 기준을 넘는지 봅니다. Search Console의 코어 웹 바이탈 보고서도 이 데이터를 보여 주며, 방문자가 적어 데이터가 부족한 페이지는 보고서에 나오지 않습니다.

그래서 PageSpeed Insights나 Lighthouse 점수가 곧 순위 점수는 아닙니다. 이 도구들의 점수는 한 번의 시험 측정값입니다. 구글은 도구에서 좋은 결과가 나와도 상위 노출이 보장되지 않고, SEO만을 위해 만점을 노리는 것은 시간을 잘 쓰는 방법이 아닐 수 있다고 밝혔습니다.

서버 응답 시간도 함께 봐야 합니다. 서버가 첫 바이트를 보내기까지 걸리는 시간(TTFB)은 코어 웹 바이탈이 아니지만 화면을 그리는 모든 단계보다 먼저 일어나서, TTFB가 길면 LCP도 늦어집니다. web.dev는 TTFB 0.8초 이하를 좋은 수준으로 봅니다. 호스팅 사양, 캐시 설정, PHP 같은 서버 프로그램의 버전과 데이터베이스 처리 속도가 TTFB를 좌우합니다.

속도가 더 크게 작용하는 곳은 수집 단계입니다

검색엔진은 페이지를 수집하고, 내용을 해석하고, 색인에 넣은 뒤에야 순위를 매깁니다. 앞 단계에서 실패한 페이지는 순위 경쟁에 들어가지 못합니다. 속도와 서버 성능이 노출에 가장 직접적으로 작용하는 지점이 여기입니다.

구글: 느려지면 크롤링을 줄입니다

구글은 크롤링 예산 문서에서 사이트가 꾸준히 빠르게 응답하면 크롤링에 쓰는 연결을 늘리고, 응답이 느려지거나 서버 오류가 나면 크롤링을 줄인다고 설명합니다. 페이지가 수만 개 이상인 큰 사이트일수록 이 차이가 커집니다.

서버 오류가 계속되면 색인에서도 빠집니다. 구글의 HTTP 오류 안내 문서에 따르면 5xx 서버 오류가 나면 크롤링 속도를 일시적으로 낮추고, 오류가 계속되는 URL은 이미 색인된 페이지라도 결국 색인에서 제외합니다.

페이지 용량에도 한도가 있습니다. Googlebot은 HTML 파일의 앞부분 2MB까지만 수집합니다. 압축을 풀기 전 크기 기준이고, CSS와 자바스크립트 파일은 따로 같은 한도가 적용됩니다. 본문에 스크립트나 이미지 데이터를 통째로 넣어 HTML이 무거워지면 뒷부분의 콘텐츠가 색인되지 않을 수 있습니다.

네이버: 수집 단계의 타임아웃과 오류를 봅니다

네이버 서치어드바이저 가이드에는 페이지 속도를 순위 기준으로 밝힌 내용이 없습니다(2026년 10월 확인). 대신 수집 단계의 문제는 분명히 다룹니다. 서치어드바이저의 수집 현황 안내는 웹 서버 연결에 시간이 오래 걸리거나 서버가 작동하지 않아 타임아웃이 나는 경우를 연결 실패로, 4xx·5xx 응답을 서버 오류로 분류합니다. 사이트맵과 RSS도 수집할 때 응답 속도가 느리면 제출이 제한될 수 있다고 안내합니다.

자바스크립트도 수집 단계의 문제입니다. 네이버는 자바스크립트 검색 최적화 가이드에서 자바스크립트 렌더링이 일반 HTML 해석보다 몇 배 이상의 자원이 드는 작업이라며, 주요 HTML 영역은 서버에서 만들어 보내는 방식(서버 사이드 렌더링)을 권장합니다. HTML 없이 자바스크립트만으로 내용을 만드는 페이지는 내용이 없는 페이지로 보고 색인에서 제외할 수 있다고도 밝혔습니다.

AI 검색은 속도 기준을 공개하지 않았습니다

GEO(생성형 엔진 최적화)는 ChatGPT, Perplexity, 구글 AI 개요 같은 생성형 AI 검색이 답을 만들 때 내 웹사이트의 콘텐츠를 출처로 쓰게 하는 작업입니다. 지금까지 공개된 문서 가운데 AI 답변의 출처를 고를 때 사이트 속도를 따로 본다고 밝힌 곳은 없습니다.

구글은 AI 기능 안내 문서에서 AI 개요와 AI 모드에 나오기 위한 추가 요건은 없고, 검색에 색인되어 스니펫과 함께 표시될 수 있는 페이지면 된다고 설명합니다. 일반 검색의 수집·색인 기준이 그대로 적용되고, 앞에서 본 크롤링 감소나 색인 제외는 AI 개요에도 똑같이 영향을 줍니다.

ChatGPT는 OpenAI 안내에 따르면 OAI-SearchBot이 검색 답변에 쓸 페이지를 미리 수집하고, 사용자가 질문하는 순간에는 ChatGPT-User가 페이지를 바로 불러오기도 합니다. OpenAI는 이 수집 봇들의 응답 시간 기준을 공개하지 않았습니다.

더 분명하게 확인된 것은 자바스크립트 처리 방식입니다. Vercel이 2024년 12월 자사 네트워크의 AI 수집 봇 요청을 분석한 결과, ChatGPT의 GPTBot, Anthropic의 ClaudeBot, PerplexityBot은 자바스크립트를 실행하지 않았습니다. 자바스크립트 파일을 내려받기는 하지만 실행하지 않아서 브라우저에서 그려지는 콘텐츠를 읽지 못합니다. 구글의 Gemini는 Googlebot 인프라를 써서 자바스크립트까지 렌더링합니다. 속도를 높이려고 본문을 자바스크립트로 나중에 불러오도록 바꾸면 이런 AI 수집 봇에는 본문이 보이지 않을 수 있습니다.

검색 서비스별로 확인된 사실

속도 개선은 서버 언어와 버전 확인부터 시작합니다

사이트 속도를 높이려면 먼저 서버에서 페이지를 만드는 언어와 그 버전을 확인합니다. 웹사이트는 PHP, 자바, 파이썬, Node.js 같은 언어로 서버에서 HTML을 만들어 보내고, 언어는 버전이 올라가면서 실행 속도와 보안이 개선됩니다. 오래된 버전을 쓰면 같은 코드라도 느리게 돌고, 새로 발견된 취약점의 보안 패치도 받지 못합니다.

예시: PHP 버전

워드프레스와 그누보드처럼 국내에서 많이 쓰는 웹사이트 프로그램은 PHP로 동작합니다. PHP 7.0이 나올 때 PHP 개발진은 5.6보다 최대 두 배 빠르다고 발표했고, 8.x에서도 버전마다 실행 엔진 개선이 이어졌습니다. 캐시를 거치지 않고 매번 새로 만드는 페이지일수록 차이가 크게 드러납니다. 실제 개선 폭은 코드와 데이터베이스, 서버 설정에 따라 다릅니다.

오래된 PHP는 서버 오류의 원인도 됩니다. 플러그인이나 테마의 새 버전이 서버보다 높은 PHP를 요구하면 페이지가 오류를 내며 멈춥니다. 호스팅 업체가 서버를 교체하면서 PHP 버전이 바뀌면, 새 버전에 맞춰 두지 않은 오래된 코드가 빈 화면이나 500 오류를 냅니다. 앞에서 본 것처럼 5xx 오류가 계속되면 색인에서 빠집니다.

보안 문제도 있습니다. 2026년 10월 21일 PHP 개발진은 로그인 없이 외부 요청만으로 서버에서 코드를 실행할 수 있는 치명적 취약점 2건(CVE-2026-109618, CVE-2026-109619, CVSS 4.0 기준 9.2점)을 공개하고 즉시 업데이트를 권고했습니다. 영향 범위는 PHP 5를 포함한 옛 버전 전체인데, 정식 패치는 지원 중인 8.2~8.5에만 나왔습니다.

해킹으로 사이트 안에 스팸 페이지가 만들어지면 구글은 이를 스팸 정책의 해킹된 콘텐츠로 보고, 검색 결과에 해킹 경고를 붙이거나 노출을 줄일 수 있습니다. 국내 사이트는 옛 버전 비중이 높습니다. 이코노미톡뉴스 보도(2026년 10월 23일)에 따르면 서버 응답에 PHP 버전이 드러난 국내 상장사 222곳 중 206곳(92.8%)이 지원이 끝난 8.1 이하를 쓰고 있었고, 그중 111곳은 5.x였습니다. 버전이 드러난 병·의원 121곳도 88.4%가 옛 버전이었습니다.

외부 스크립트와 API 호출

서버 언어 다음으로 볼 것은 페이지에 붙어 있는 외부 요소입니다. 광고·분석 태그, 채팅 상담 창, 지도나 동영상 삽입처럼 다른 회사 서버에서 불러오는 자바스크립트는 그 서버와 새로 연결하고 파일을 받아 실행하는 시간만큼 로딩을 늦춥니다. web.dev의 외부 자바스크립트 안내는 외부 스크립트를 문서 해석 도중에 동기식으로 불러오면 나머지 문서의 해석이 늦어지고, 여러 서버에 요청을 많이 보내면 느려진다고 설명합니다.

서버 쪽에서도 같은 일이 생깁니다. 페이지를 만들 때 예약 현황이나 재고 같은 정보를 외부 API에서 받아 오는 구조라면, 그 API가 늦게 응답하는 만큼 서버의 첫 응답(TTFB)도 늦어집니다. 쓰지 않는 태그와 위젯을 정리하고, 외부 API 결과는 캐시에 담아 두면 줄일 수 있습니다.

언어 버전을 올리거나 외부 요소를 정리한다고 검색 순위가 바로 오르지는 않습니다. 하지만 오래된 서버 언어와 무거운 외부 요소는 속도와 서버 오류, 보안에서 위험이 되고, 그 위험은 검색 노출의 전제인 수집과 색인을 흔듭니다. 특히 PHP 8.1 이하를 쓰는 사이트라면 지원 버전으로 올리는 일이 다른 최적화보다 먼저입니다.

자주 하는 오해

• “PageSpeed 점수가 높아야 상위에 노출된다” 점수는 시험 측정값이고, 구글이 보는 코어 웹 바이탈은 실제 방문자 데이터입니다. 구글은 도구 점수가 좋아도 상위 노출이 보장되지 않는다고 밝혔습니다.
• “사이트가 빠르면 AI가 더 많이 인용한다” 구글과 OpenAI 모두 AI 답변의 출처를 고를 때 쓰는 속도 기준을 공개하지 않았습니다. 확인된 사실은 수집되지 않은 페이지는 인용될 수 없다는 점입니다.
• “콘텐츠가 좋으면 속도는 상관없다” 순위에서는 관련성이 먼저입니다. 하지만 응답이 늦거나 서버 오류가 잦으면 수집이 줄고, 오류가 계속되면 색인에서 빠집니다. 수집되지 않은 콘텐츠는 품질과 관계없이 노출되지 않습니다.

확인할 항목

• Search Console 코어 웹 바이탈 보고서. 실제 방문자 기준으로 LCP, INP, CLS가 좋음인지 확인합니다.
• Search Console 크롤링 통계 보고서. 평균 응답 시간과 호스트 상태, 서버 오류 비율을 봅니다.
• 네이버 서치어드바이저 수집 현황. 연결 실패와 서버 오류가 기록되고 있는지 확인합니다.
• 서버 언어 버전. 사이트가 쓰는 언어가 지원 중인 버전인지 확인합니다. PHP라면 8.2 이상인지, 10월 21일 보안 패치(8.2.35, 8.3.36, 8.4.27, 8.5.12) 이상이 적용됐는지 봅니다. 8.2는 2026년 12월 31일에 지원이 끝나므로 8.4나 8.5로 옮길 계획도 세웁니다.
• 서버 응답 시간. 주요 페이지의 TTFB가 0.8초 안팎인지 보고, 느리면 캐시 설정, 서버 언어 버전, 호스팅 사양을 점검합니다.
• 외부 스크립트와 API. 페이지에 붙은 광고·분석 태그, 채팅 상담 창, 삽입 동영상과 서버가 기다리는 외부 API 호출을 점검하고, 쓰지 않는 것은 뺍니다.
• 첫 HTML의 본문. 브라우저의 페이지 소스 보기에서 본문 문장이 검색되는지 확인합니다. 보이지 않으면 자바스크립트를 실행하지 않는 수집 봇도 본문을 읽지 못합니다.
• 페이지 용량. HTML이 2MB를 넘지 않는지, 이미지가 화면 크기에 맞게 압축되어 있는지 확인합니다.

속도는 노출의 전제 조건에 가깝습니다

사이트 속도는 구글 순위에 쓰이는 신호지만, 관련성과 콘텐츠 품질을 넘어서지는 못합니다. 영향이 분명하게 드러나는 곳은 수집 단계입니다. 응답이 느리거나 오류가 나는 서버, 자바스크립트를 실행해야만 본문이 보이는 페이지는 검색엔진과 AI가 콘텐츠를 가져가는 단계에서 막힙니다. 속도와 서버 성능은 순위를 올리는 수단이라기보다, 콘텐츠가 검색과 AI 답변에 들어가기 위한 조건으로 관리해야 합니다. 서버 쪽에서는 사이트가 쓰는 언어를 지원 중인 버전으로 유지하는 것이 그 첫 단계입니다.

사이트 속도 점검이나 PHP 같은 서버 언어의 버전 업그레이드가 필요하시면 BPXG에 편하게 문의해 주세요. 호환성 점검부터 전환, 전환 뒤 검색 수집 상태 확인까지 함께 진행합니다.

자주 묻는 질문

참고 자료

아래는 본문 서술의 바탕이 된 공개 자료입니다.

• Google 검색 센터 — Google 검색 결과의 페이지 경험 이해하기
• Google 검색 센터 — HTTP 상태 코드, 네트워크 및 DNS 오류가 Google 검색에 미치는 영향
• 네이버 서치어드바이저 — 자바스크립트 검색 최적화 가이드
• Vercel — The rise of the AI crawler(2024년 12월)
• PHP — Security advisory: Critical remote code execution vulnerabilities, update now(2026년 10월 21일)