블로그 검색엔진 최적화 작업 기록 — robots.txt, sitemap, Search Console까지 한 번에 정리
이 글은 검색 노출이 약한 블로그에 검색엔진 최적화 작업을 적용하고, 실제 운영 도메인에서 Search Console 제출까지 마친 과정을 정리한 기록이다.
먼저 SEO가 무엇인지부터 짚고 가면, SEO는 Search Engine Optimization의 줄임말로 보통 검색엔진 최적화라고 번역한다. 쉽게 말하면 Google 같은 검색엔진이 내 사이트를 더 잘 이해하고, 더 잘 찾고, 더 적절하게 보여주도록 만드는 작업이다.
이 작업은 단순히 키워드를 많이 넣는 게 아니다. 검색엔진이 페이지를 읽을 기술적 단서를 주는 일, 사람이 클릭할 만한 제목과 설명을 만드는 일, 그리고 사이트 안에서 관련 글을 자연스럽게 이어 주는 일까지 다 포함한다.
처음 문제는 단순했다. 글은 계속 올라가는데 검색엔진에서 거의 보이지 않았다. 처음에는 "제목이 별로인가?"부터 떠올랐지만, 코드를 뜯어보니 더 기본적인 문제가 있었다. 검색엔진이 사이트를 이해하는 데 필요한 신호 자체가 부족했다.
이번 작업은 그걸 세 층으로 나눠서 정리한 과정이었다.
- 기술 SEO 기반 추가
- 기존 글 전체 리라이트
- 실제 Search Console 제출과 초기 색인 요청
처음 확인한 문제
처음 코드 상태는 이런 쪽에 가까웠다.
- 기본
title,description정도만 있음 robots.txt,sitemap.xml없음- canonical 없음
- Open Graph / Twitter 메타 부족
BlogPostingJSON-LD 없음
즉 사람은 페이지를 읽을 수 있지만, 검색엔진은 이 사이트를 충분히 이해하기 어려운 상태였다.
여기서 핵심은 "글 품질이 낮다"보다 먼저, 검색엔진이 이 사이트를 읽을 최소한의 단서가 없었다는 점이었다.
검색엔진이 읽을 수 있는 신호부터 깔았다
제일 먼저 한 일은 ai-survival-log-site의 메타데이터 기반을 잡는 것이었다.
추가한 것은 아래다.
- 전역
metadataBase - 페이지별 canonical
robots.txtsitemap.xml- 포스트 상세
openGraph,twitter - 포스트 상세
BlogPostingJSON-LD
여기서 느낀 점은 명확했다. 검색 노출 문제는 종종 "제목만 잘 쓰면 된다"로 축약되지만, 실제로는 그 전에 검색엔진이 페이지를 발견하고 대표 URL을 판단하고 문서 타입을 이해할 수 있어야 한다.
즉 기술 SEO는 옵션이 아니라 바닥 공사에 가까웠다.
제목은 톤을 유지하되, 검색용 타이틀은 따로 만들었다
기술 SEO만 넣는다고 끝나지는 않았다.
기존 글들을 다시 보니 이런 패턴이 있었다.
- 제목은 톤이 좋은데 검색 질의와 직접 맞물리진 않음
- 도입부가 감성이나 맥락으로 시작해서 주제가 늦게 나옴
- 관련 글로 이어지는 링크가 부족함
그래서 전체 글에 공통으로 아래를 적용했다.
seoTitle추가seoDescription추가- 첫 문단에서 "이 글이 무엇을 설명하는가"를 더 빨리 드러내도록 수정
- 글 하단에 관련 글 링크 추가
여기서 중요한 기준은 하나였다.
화면에 보이는 기본 제목은 톤을 유지하되, 검색용 제목과 설명은 더 직접적으로 가져간다.
이 방식이 좋은 이유는, 블로그의 개성을 완전히 버리지 않으면서도 검색 결과에서는 더 분명한 문장으로 대응할 수 있기 때문이다.
감으로 쓰면 다음 글에서 다시 흐려진다
한 번 고쳐 놓고 끝내면 다음 글부터 다시 감으로 쓰게 된다.
그래서 이번에는 단순히 글 몇 개를 손보는 데서 멈추지 않고, 앞으로도 같은 기준을 따를 수 있도록 작성 규칙을 문서화했다.
핵심 규칙은 이런 식이다.
- 검색형 글은 핵심 개념어를 제목 또는
seoTitle에 직접 포함 - 첫 2~3문단 안에 글의 질문과 답변 범위를 명시
description은 요약 역할을 하게 작성- 관련 글 2개 이상 연결
- 시리즈화 가능한 글은 시리즈 구조를 먼저 고려
이 문서를 만든 이유는 분명하다.
검색 우선순위는 "나중에 배포 단계에서 붙이는 장식"이 아니라, 글을 쓰는 순간부터 고려해야 하는 설계 규칙이기 때문이다.
코드를 넣는 것과 실제 색인은 전혀 다른 일이었다
기술 SEO와 글 수정이 끝났다고 해서 작업이 끝난 건 아니었다.
실제 운영 도메인에서 아래를 직접 확인해야 했다.
robots.txtsitemap.xml- 대표 글의 canonical
og:title,og:image- JSON-LD 존재 여부
그 다음에야 Google Search Console에서:
- 도메인 인증
sitemap.xml제출- 대표 글 URL 검사
- 색인 생성 요청
까지 진행할 수 있었다.
이 단계를 지나고 나서야 "SEO 작업을 했다"는 말이 어느 정도 성립한다는 걸 체감했다.
문서를 적어두는 것과 실제 Search Console에서 상태를 보는 것은 전혀 다른 일이다.
이번 작업에서 배운 점
기술 SEO와 콘텐츠 SEO는 같이 봐야 한다
둘 중 하나만 하면 반쪽짜리다.
- 기술 SEO만 있으면: 검색엔진은 읽을 수 있지만 클릭할 이유가 약하다
- 콘텐츠 SEO만 있으면: 제목은 좋아도 검색엔진이 페이지를 제대로 이해하지 못한다
둘이 같이 가야 한다.
검색 규칙은 upstream에도 있어야 한다
이번 블로그는 ai-survival-log에서 초안과 시리즈 구조가 먼저 잡히고, ai-survival-log-site가 최종 소비층 역할을 한다.
그래서 검색형 제목, 설명문, 도입부, 내부 링크 기준은 site repo에만 있으면 늦다. 실제 작성이 일어나는 upstream에도 같은 규칙이 있어야 했다.
Search Console은 “배포 후 운영”의 시작점이다
이번에 가장 크게 느낀 건 이 부분이다.
SEO는 코드를 넣는 순간 끝나는 게 아니라, 그때부터 운영이 시작된다.
이제부터는 Search Console에서:
- 색인 수
- 노출 수
- CTR
- 평균 순위
를 보고 다시 제목과 설명을 조정해야 한다.
즉 이번 작업은 완료라기보다, 첫 번째 운영 루프를 연 것에 가깝다.
지금 상태
현재 블로그는 다음 상태가 됐다.
- 기술 SEO 기본기 확보
- 기존 글 전체 1차 리라이트 완료
- 콘텐츠 SEO 작성 가이드 문서화
- Search Console 도메인 인증 및 sitemap 제출 완료
- 대표 글 URL 검사 및 색인 생성 요청 완료
이제 남은 건 기다리면서 데이터를 보는 일이다.
검색 노출이 실제로 어떻게 변하는지, 어떤 글이 impressions는 있는데 CTR이 낮은지, 어떤 글은 제목을 더 직접적으로 바꿔야 하는지를 봐야 한다.
작업은 끝났지만, 운영은 이제 시작이다.
이어 읽기
시리즈는 순서대로, 편집 추천은 맥락대로, 비슷한 주제는 태그 기준으로 정리합니다.
함께 읽으면 좋은 글
편집 추천비슷한 주제의 글
태그가 겹치는 글입니다. 시리즈와 편집 추천에 이미 나온 글은 제외합니다.
AI 웹개발 기초: 프론트엔드 1-5 | SPA, SSR, Next.js는 어떤 기준으로 골라야 할까
SPA/MPA와 CSR/SSR/SSG를 서로 다른 축으로 나누고, SEO가 필요한 공개 URL과 로그인 후 업무 화면에서 Next.js App Router, Server/Client Component, cache/revalidation, streaming을 어떤 기준으로 선택할지 정리하는 AI 웹개발 기초 시리즈 프론트엔드 1-5.
정답보다 사람향
AI와 함께 공부하고 기록하며 AI향을 흡수하되, 핵개인 시대의 브랜딩은 질문 선택, 판단 이유, 오답의 결에서 남는 사람향으로 돌아온다는 에세이.
코드트리 후기: 코딩테스트 준비를 갭체크로 시작했다
CodeTree 갭체크 결과를 바탕으로 코딩테스트 준비에서 조건문과 시뮬레이션은 해결했지만 백트래킹 문제를 건너뛰게 된 이유를 돌아보고, 재귀 호출과 상태 복구를 다음 학습 목표로 잡은 후기.