구글: 에? 처음부터 없었는데요?

어쩐지... 색인 생성이 안되더라니... SEO를 망친 문제들

Jun Noh
#nginx #SEO #Azure #Postmortem #301

나는 원래 내 블로그의 글을 검색해본다거나 하지 않는다.

매일 일기 형식으로 쓰는 블로그기도 하고.. 이게 노출이 얼마나 되던 상관이 없으니까.

근데 Google Search Console에서 며칠 전부터 자꾸 이상한 메일이 날아왔다.

“색인이 생성되지 않은 이유를 분석해보세요.”

엥? 그럴리가 없는데? 하고 꽤 오래 전에 쓴 글 하나를 검색해봤다.

안나온다.

다른 것들도 하나하나 찾아봤는데…

전부 다 안 나온다.

이럴리가 없는데 싶어서 아예 site:slowflowsoft.com/blog 로 검색해봤다. 최근 글은 하나도 없고, 오래된 글 몇 개만 조각조각 걸려있었다.

이상한 발견

일단 뭐가 문제인지 감이 안 잡히니까 홈페이지 접속해서 이것저것 눌러봤다.

블로그 메인은 잘 뜬다. https://www.slowflowsoft.com/blog 그대로 있음.

근데 여기서 아무 글이나 하나 클릭했더니 —

https://www.slowflowsoft.com/blog                      ← 여기 있다가
   ↓ (블로그 글 클릭)
https://slowflowsoft-web.nicecliff-....azurecontainerapps.io/blog/xxx/   ← 여기로 튐

주소창의 도메인이 완전히 딴 걸로 바뀌었다.

내 도메인(slowflowsoft.com) 에 있다가 → 뒤에 숨어있어야 할 Azure Container Apps 의 원본 주소로 튀는 것.

심지어 https:// 가 http:// 로 다운그레이드까지 된다.

“어… 이러니까 색인을 못하지..”

왜 색인이 안되냐면,

이걸 이해하려면 검색엔진이 뭘 하는지 잠깐 생각해봐야 한다.

Google 봇이 내 블로그를 크롤링하러 들어온다.

www.slowflowsoft.com/blog/xxx 를 방문하려는데, 서버가 이렇게 답한다.

“그 주소 아니에요. 이제 그 글은 slowflowsoft-web.nicecliff-....azurecontainerapps.io/blog/xxx/ 로 이사갔어요. 앞으로 여기로 오세요.”

이게 301 Moved Permanently 라는 응답이다. “영구적으로 이사갔다” 는 뜻.

Google 은 이걸 곧이곧대로 믿는다.

  • “아 이 글의 진짜 주소는 저 Azure 주소구나”
  • 커스텀 도메인 주소는 인덱스에서 제거
  • Azure 주소를 canonical(정본) 로 기록
  • 근데 그 Azure 주소는 아무도 검색하지 않으니 결과에 안 뜸

내 블로그 글이 Google 에서 조용히 실종되고 있었던 이유.

근데 왜 튀지?

일단 curl 로 확인해봤다.

$ curl -sI https://www.slowflowsoft.com/blog/some-post
HTTP/2 301
location: http://slowflowsoft-web.nicecliff-...azurecontainerapps.io/blog/some-post/

ㅇㅇ… 서버가 대놓고 튕겨내고 있음.

그럼 이 301 을 누가 쏘는 걸까?

내 스택은 이렇게 생겼다.

[유저 브라우저] → [Azure Front Door] → [Azure Container App] → [nginx + 정적 파일]

Front Door 쪽 설정을 아무리 뒤져봐도 리다이렉트 규칙은 없다. 그럼 남은 건 nginx 뿐.

원인 — 멍청헀던 nginx 셋팅

nginx 설정을 뜯어봤다.

location /blog/ {
    alias /usr/share/nginx/html/blog/;
    try_files $uri $uri/ /blog/index.html;
}

문제는 여기서 발생한다.

내 블로그 링크는 /blog/some-post (뒤에 슬래시 없음) 로 걸려있고, 실제 파일은 /blog/some-post/index.html 이다.

유저가 /blog/some-post 로 요청을 넣으면 nginx 가 이런 판단을 한다.

“어 이건 파일이 아니라 디렉토리네? 뒤에 슬래시가 있어야 정상이지.” “그럼 /blog/some-post/ 로 다시 오라고 안내해야겠다.”

이 안내를 만드는 게 301 리다이렉트.

여기서 진짜 문제.

nginx 가 이 안내에 “새 주소” 를 적을 때, 유저가 처음 요청한 주소(www.slowflowsoft.com) 를 그대로 쓰는 게 아니라, 자기 자신의 hostname 을 쓴다. 이게 기본 동작이다.

컨테이너의 hostname 이 slowflowsoft-web.nicecliff-....azurecontainerapps.io 이니까 그게 그대로 튀어나가는 것.

비유하자면 이런 상황이다.

카페에 손님이 들어와서 “화장실 어디예요?” 물어봤다.
종업원이 “저쪽으로 가세요” 하고 손가락으로 가리키는 대신 —
“저희 카페 이름은 ‘고래카페’ 인데 뒷문 주소는 ‘메타몽 빌딩 지하 3층’ 이니 거기로 다시 오세요” 라고 답한 격.

손님은 “아 여기 원래 이 주소구나” 하고 그 주소를 기억한다. 다음번에도 그리로 온다. Google 도 마찬가지.

이 동작을 결정하는 nginx 지시자가 세 개.

  • absolute_redirect — 켜져 있으면 절대 주소로 리다이렉트 (기본 켜짐)
  • server_name_in_redirect — 켜져 있으면 서버 자체 이름을 씀 (기본 켜짐)
  • port_in_redirect — 포트도 굳이 붙임 (기본 켜짐)

세 개 다 켜져있는 게 nginx 의 기본값. 뒤에 CDN 이든 프록시든 뭐가 있든 신경 안 쓰고 자기 이름을 쫑알쫑알 흘림.

수정 — 세 줄로 끝

nginx.conf 의 server 블록에 세 줄만 추가.

server {
    listen 80 default_server;
    server_name _;

    absolute_redirect off;
    server_name_in_redirect off;
    port_in_redirect off;

    # ... 기존 설정
}

이제 nginx 는 리다이렉트할 때 상대 경로만 뱉는다. Location 헤더에 /blog/some-post/ 만 들어가고, 브라우저가 알아서 현재 도메인에 붙여서 해석 → 도메인 유지.

이왕 하는 김에 링크도 정리

nginx 는 고쳤는데, 301 이 발생하는 것 자체는 여전하다. /blog/some-post → /blog/some-post/ 로 한 번 튀는 게 남아있음. 이거 자체가 뭐 큰 문제는 아닌데 — 크롤 예산 낭비고, 페이지 로딩도 살짝 늦어짐.

그래서 아예 링크에 슬래시를 붙여버렸다.

<!-- Before -->
<a href={`/blog/${post.slug}`}>

<!-- After -->
<a href={`/blog/${post.slug}/`}>

블로그 / 서브노트 / 스토리 다 뒤져서 총 11개 파일 수정. 이제 링크 클릭하면 301 없이 바로 200 OK.

SEO 회복은 이제 기도

nginx 만 고치면 다음에 Google 이 크롤 하러 왔을 때 알아서 정상 URL 로 재인덱싱 시작. 근데 그게 자동으로 되는 데 며칠~수주 걸린다.

빠르게 회복하려면 Google Search Console 에서 손으로 요청해야 한다.

  1. sitemap 재제출 — 정상 URL 목록을 알려주기
  2. 주요 페이지 URL 검사 → “색인 요청” — 페이지별 수동 색인 요청. 하루 10~20개 정도

처음에 노출은 안중요하고 어쩌구… 하긴 했는데, 그래도 좋은게 좋은거라고 색인 생성을 계속 눌렀다.ㅋㅋㅋㅋ

마치며

예, 뭐 그렇습니다ㅋㅋㅋ

다 보여주려고 글 쓰는 거 아닙니까.

게시글 100개가 넘는 블로그 방문자가 주니어 때 쓰던 티스토리보다 적으면 안되니까…

마침.

목록으로 가기

다른 글 보기