사람 눈엔 멀쩡한 페이지가 구글에는 「에러 화면」이었습니다

「이 페이지 왜 검색에 안 잡히죠?」
서버 응답은 정상이었고, 사람이 브라우저로 열면 멀쩡했고, 글에도 문제가 없었습니다.

그런데 구글 서치콘솔의 실시간 테스트는 세 번 연속 같은 판정을 냈습니다. 소프트 404, 응답은 정상인데 내용이 없다고 보는 상태입니다.

9월 10일 저희가 운영을 돕는 국내 서비스 한 곳에서 겪은 일입니다. 원인은 글이 아니라 로딩 실패였고, 대표가 가져갈 것은 그 화면을 직접 보는 자리 한 곳입니다.

사람 눈에 멀쩡한 페이지와 구글이 본 페이지는 다른 화면일 수 있습니다.
그날 저희 기록은 이렇게 시작합니다.

실시간 테스트는 서치콘솔에서 주소 하나를 넣으면 구글이 지금 그 페이지를 열어 보고 판정을 돌려주는 기능입니다. 12분 사이 세 번을 돌렸고 세 번 다 소프트 404 였습니다.

소프트 404 는 서버가 「정상(200)」이라고 답했는데 구글이 내용을 보니 빈 페이지나 오류 메시지라고 판단하는 상태입니다. 구글 문서는 이렇게 적습니다.

구글이 찍은 스크린샷에는 본문이 없었습니다. 「애플리케이션 오류: 클라이언트 쪽 예외가 발생했습니다」 한 줄이 전부였습니다.

이 화면을 보기 전까지 저희도 글 쪽을 의심했습니다. 본문이 짧은가, 제목이 겹치나. 화면을 보고서야 질문이 바뀌었습니다.

구글에게 그 페이지는 글이 아니라 에러 화면 한 장이었습니다.

같은 테스트 화면의 「추가 정보」 탭에 답이 있었습니다.
페이지를 그리는 데 필요한 파일 목록과 그 결과입니다.

요즘 웹 페이지는 파일 하나로 오지 않습니다. 화면을 조립하는 데 필요한 조각(청크) 수십 개를 브라우저가 따로 받아 맞춥니다.

그날 필요한 조각은 39개였고 구글 렌더러는 그중 8개를 못 받았습니다. 못 받은 조각 셋은 저희 쪽 파일이었고, 그 실패가 화면 조립 전체를 멈춰 세웠습니다.

서버가 문제였을까요. 아니었습니다.

세 조각은 모든 페이지가 공유하는 뼈대 파일이었습니다. 서버에 직접 요청하면 0.06초 만에 정상으로 왔습니다.

일반 브라우저로 열어도, 구글 봇인 척 열어도, 외부 스크립트와 저장소를 막고 열어도 재현되지 않았습니다. 구글 렌더러가 페이지를 여는 그 순간에만 조각 몇 개가 안 온 것입니다.

구글이 왜 그 요청을 실패시키는지는 확인되지 않았습니다. 호스트 부하 제한이나 렌더 예산 같은 후보가 있지만 저희가 실측한 것은 아니고, 이 글에서는 가정으로만 둡니다.

확실한 것은 하나입니다. 뼈대 조각 하나가 안 오면 화면 전체가 죽는 구조였고, 그 구조에서는 어떤 페이지든 같은 방식으로 검색에서 빠질 수 있었습니다.

「우리 쪽에서는 잘 된다」는 증거가 아닙니다.

글은 한 글자도 고치지 않았습니다.
조각을 못 받았을 때 한 번 더 받는 장치를 넣었습니다.

조각을 못 받으면 1.5초 뒤, 3초 뒤, 4.5초 뒤에 다시 받습니다. 세 번 다 실패하면 예전과 같은 오류 화면입니다.

넣기 전에 두 가지를 확인했습니다. 한두 번 실패했을 때 복구되는가, 전부 실패했을 때 예전 실패 모습이 그대로인가. 둘 다 확인하고 배포했습니다.

배포 뒤 결과입니다.

같은 페이지가 1분 만에 「색인 생성 가능」이 됐습니다. 그때도 구글 렌더러는 조각 39개 중 18개를 못 받았지만, 재시도가 뼈대 조각을 살려 화면이 조립됐습니다.

그날 여섯 편의 색인 요청을 넣었습니다. 세 편은 하루 할당량이 차서 다음 날로 넘겼습니다.

재시도가 실패 자체를 없앤 것은 아닙니다. 실패 횟수는 오히려 늘었습니다. 바뀐 것은 실패 한 번이 화면 전체를 죽이지 않게 된 것뿐입니다.

재시도 세 번이 콘텐츠 열 편보다 노출에 더 큰 차이를 만들었습니다.

이 원인을 찾는 데 개발 지식은 필요 없었습니다.
서치콘솔 화면 한 곳을 열 줄 알면 됩니다.

서치콘솔 상단 검색창에 페이지 주소를 넣으면 「URL 검사」가 열립니다. 거기서 「실시간 테스트」를 누르면 구글이 지금 그 페이지를 열어 봅니다.

판정이 나오면 「테스트된 페이지 보기」를 누릅니다. 구글 도움말이 그 안에 무엇이 있는지 적어 두었습니다.

볼 것은 세 탭입니다. 「스크린샷」에는 구글이 본 화면이, 「추가 정보」의 「페이지 리소스」에는 못 받은 파일 목록이, 「자바스크립트 콘솔」에는 실패 메시지가 있습니다.

저희가 그날 작업 기록에 규칙으로 추가한 문장입니다.

스크린샷이 본문 대신 오류 한 줄이면 글 문제가 아닙니다. 페이지 리소스에 자사 파일이 실패로 찍혀 있으면 로딩 문제입니다.

이 세 탭을 대표가 직접 열 줄 알면 외주에 「SEO 해 주세요」로 돈을 쓰기 전에 원인의 절반은 가를 수 있습니다. 글을 고칠 일인지 로딩을 고칠 일인지가 거기서 갈립니다.

서치콘솔의 「테스트된 페이지 보기」가 답을 갖고 있습니다.

검색 노출은 「글」 한 층이 아닙니다.
그 아래 「구글이 실제로 본 화면」 층이 하나 더 있습니다.

구글 문서도 페이지를 세 단계로 처리한다고 적습니다. 가져오고, 그리고, 색인합니다.

그리는 단계에서 화면이 안 나오면 색인할 내용이 없습니다. 글이 아무리 좋아도 그 층에서는 0 입니다.

그날 저희가 글 품질을 먼저 의심했다면 며칠을 잃었을 것입니다. 실시간 테스트 세 번과 스크린샷 한 장이 방향을 바꿨습니다.

대표님이 가져갈 칸은 셋입니다.

「검색에 안 나온다」의 첫 질문을 「구글이 본 화면이 무엇이었나」로 적는다.
「우리 쪽에서는 잘 된다」를 증거로 받지 않고 「구글이 열었을 때 떴는가」를 따로 확인한다.
필요한 파일 하나가 안 오면 화면 전체가 죽는 구조에 「한 번 더」가 있는지 묻는다.

대표는 구글이 본 화면 하나만 볼 줄 알면 됩니다.

정리

경고 신호

• 「검색에 안 나온다」에 글 품질부터 고치기 시작한다

• 「우리 쪽에서는 잘 뜬다」가 확인의 전부다

• 서치콘솔 실시간 테스트를 돌려 본 적이 없다

• 파일 하나를 못 받으면 화면 전체가 죽는데 재시도가 없다

좋은 신호

• 첫 질문이 「구글이 본 화면이 무엇이었나」다

• 서치콘솔 스크린샷·페이지 리소스·콘솔 세 탭을 대표가 직접 연다

• 로딩 실패에 재시도 장치가 있고 전부 실패했을 때의 모습도 확인돼 있다

• 「소프트 404」 판정을 받으면 글보다 로딩을 먼저 본다

외주에 「SEO」를 맡기기 전에 정할 네 가지

1. 서치콘솔 실시간 테스트에서 구글이 찍은 스크린샷에 본문이 있습니까?
   오류 한 줄이면 글이 아니라 로딩 문제입니다.

2. 「페이지 리소스」에 실패로 찍힌 자사 파일이 있습니까?
   뼈대 파일이 실패했다면 어떤 페이지든 같은 방식으로 빠질 수 있습니다.

3. 「우리 쪽에서는 잘 된다」 말고 구글이 열었을 때의 결과를 확인했습니까?
   검색엔진은 사람 브라우저와 다른 조건으로 페이지를 엽니다.

4. 파일을 못 받았을 때 「한 번 더」 받는 장치가 있습니까?
   재시도 세 번이 콘텐츠 열 편보다 노출에 더 큰 차이를 만듭니다.

자주 묻는 질문

Q. 소프트 404 가 정확히 무엇입니까?

서버는 정상(200)이라고 답했는데 구글이 내용을 보고 빈 페이지나 오류 메시지라고 판단하는 상태입니다. 구글 문서는 내용이 오류·빈 페이지·오류 메시지를 시사하면 서치콘솔이 소프트 404 를 표시한다고 적습니다.

Q. 사람이 열면 멀쩡한데 구글만 실패하는 일이 정말 있습니까?

있습니다. 9월 10일 저희 사례에서 일반 브라우저, 구글 봇인 척한 브라우저, 외부 스크립트와 저장소를 막은 브라우저 모두 재현되지 않았고 구글 렌더러만 조각 39개 중 8개를 못 받았습니다. 왜 실패시키는지는 확인되지 않았습니다.

Q. 어디서 확인합니까?

서치콘솔 URL 검사에서 실시간 테스트를 돌린 뒤 「테스트된 페이지 보기」를 누릅니다. 스크린샷 탭에 구글이 본 화면, 추가 정보의 페이지 리소스와 자바스크립트 콘솔에 실패한 파일과 메시지가 있습니다.

Q. 재시도를 넣으면 실패가 없어집니까?

없어지지 않습니다. 저희 사례는 조치 뒤에도 조각 18개가 실패했지만 재시도가 뼈대 조각을 살려 「색인 생성 가능」이 됐습니다. 재시도까지 전부 거부되면 예전과 같은 오류 화면입니다.

Q. 글을 고쳐야 하는지 로딩을 고쳐야 하는지 어떻게 가릅니까?

구글이 찍은 스크린샷에 본문이 보이면 글 쪽, 오류 한 줄이나 빈 화면이면 로딩 쪽입니다. 저희는 이 순서를 작업 기록에 규칙으로 적어 두었습니다.