작은 블로그를 다시 검색엔진에 제출하면서 확인한 것들

7월 7일, 다시 연 RLAX에 글을 더 쓰기 전에 검색엔진부터 열었다.

정확히는 내가 직접 세 개의 관리자 화면을 붙잡고 있었던 건 아니다. 크롬에 Google, Naver, Bing 계정을 로그인해두고 AI에게 주요 주소의 색인 상태를 확인하고 필요한 요청을 진행해달라고 했다. 요즘 내가 AI를 쓰는 방식과 블로그를 다시 운영하는 일이 처음으로 제대로 만난 작업이었다.

처음에는 꽤 단순하게 생각했다. 사이트맵을 제출하고, 최근 글 몇 개에 색인 요청을 누르면 끝. 새로 만든 사이트도 아니고 2021년부터 있던 도메인이니, 검색엔진이 이미 어느 정도는 알고 있을 거라고 생각했다.

그런데 공개돼 있다는 것과 발견돼 있다는 것은 전혀 다른 일이었다. Google은 어떤 주소는 알고도 검색 결과에 넣지 않았고, Naver에서는 수집 요청 버튼을 눌렀는데 접수됐다는 흔적이 남지 않았다. Bing은 현재 쓰지 않는 www.rlax.kr을 사이트 이름처럼 보여주고 있었다.

같은 사이트를 세 군데에 내밀었는데, 돌아오는 대답이 전부 달랐다.

5년 동안 거의 벌지 못한 블로그를 다시 연 날에는 서버를 다시 만들고 글을 남기는 데만 마음이 가 있었다. 사흘 뒤 사이트맵을 등록했고, 다시 사흘이 지나서야 알았다. 발행 버튼을 누른 뒤에도 생각보다 할 일이 많았다.

사이트맵 하나면 될 줄 알았다

WordPress는 기본 사이트맵을 만들어준다. RLAX의 현재 사이트맵은 https://rlax.kr/wp-sitemap.xml이다. Google Search Console에서 이 주소는 성공으로 표시됐고, 7월 7일 기준 64개의 페이지를 발견한 것으로 나왔다.

여기까지만 보면 별문제가 없어 보였다. 문제는 그 아래에 남아 있던 예전 주소들이었다. https://www.rlax.kr/sitemap.xml, http://rlax.kr/sitemap.xml, http://www.rlax.kr/sitemap.xml. 지금은 쓰지 않는 http와 www 조합이 실패 기록으로 남아 있었다.

이런 화면을 보면 먼저 지우고 싶어진다. 빨간 실패 표시가 있으면 사이트 전체가 잘못된 것처럼 느껴지니까. 나도 처음에는 오래된 사이트맵을 정리해야 하나 싶었다. 하지만 지금 RLAX의 페이지가 가리키는 기준 주소와 현재 사이트맵은 모두 https://rlax.kr/로 맞아 있었다. 과거의 실패 기록보다 현재 주소가 제대로 읽히고 있는지가 먼저였다.

사이트맵 성공은 검색엔진에 목차를 건넸다는 뜻에 가까웠다. 그 목차에 있는 글이 전부 검색 결과에 들어갔다는 뜻은 아니었다. Google 공식 문서도 사이트맵 제출은 힌트일 뿐, 크롤링이나 색인을 보장하지 않는다고 설명한다. 알고 있던 말인데 실제 화면에서 보니 조금 다르게 느껴졌다.

글을 발행했으니 당연히 검색될 거라는 생각과, 검색엔진이 사이트맵을 읽었으니 곧 들어갈 거라는 생각은 거의 같은 착각이었다.

Google은 주소마다 다른 말을 했다

홈페이지는 이미 Google에 색인돼 있었다. 도메인을 오래 쓴 덕인지 최소한 사이트 자체는 알고 있었다. 그런데 최근 글과 주요 페이지를 하나씩 검사하자 상태가 갈렸다.

특히 “발견됨 – 현재 색인이 생성되지 않음”이라는 말이 묘했다. 주소를 모르는 것도 아니고, 오류가 났다는 것도 아니다. Google은 페이지의 존재를 알지만 아직 검색 결과에 넣지는 않았다고 했다. 이 상태에서는 버튼을 한 번 더 누르는 것보다 왜 이 페이지를 먼저 읽어야 하는지를 사이트 안에서 만들어주는 일이 더 중요해 보였다.

소개 페이지가 아예 알려지지 않은 주소로 나온 것도 의외였다. 블로그 입장에서는 기본 페이지지만, 검색엔진 입장에서는 다른 글에서 충분히 연결되지 않은 조용한 주소였을 수 있다. 그래서 색인 요청과 함께 홈, 글 하단 작성자 소개, 편집 정책에서 소개 페이지로 이어지는 링크를 다시 보게 됐다.

이때부터 내부 링크를 단순한 SEO 장치로 보지 않게 됐다. 검색엔진에 “이 글도 읽어달라”고 말하는 동시에, 처음 들어온 사람에게 이 사이트가 어디서 시작해 어디로 이어지는지 알려주는 편집의 문제였다.

Naver는 아무 말도 하지 않는 방식으로 실패했다

Naver Search Advisor 쪽은 시작할 때 오히려 가장 멀쩡해 보였다. https://rlax.kr 사이트가 등록돼 있었고 HTTPS 인증서와 리다이렉션도 정상으로 확인됐다. WordPress 사이트맵은 7월 4일 오후 2시 43분에 등록돼 있었고, 홈 주소의 수집 요청 기록도 같은 날 남아 있었다.

그렇다면 최근 글 여섯 개만 더 요청하면 될 것 같았다. 주소를 넣고 수집 요청 버튼을 눌렀다. 화면 한쪽에 작은 경고 알림이 나타났지만, 무슨 내용인지 확인할 수 있을 만큼 분명하지 않았다. 더 중요한 것은 요청 내역에 새 주소가 한 줄도 생기지 않았다는 점이었다.

버튼은 눌렸다. 하지만 접수됐다는 증거는 없었다.

이런 상황이 제일 애매하다. 오류 문구가 선명하면 원인을 찾으면 되고, 성공 기록이 남으면 기다리면 된다. 아무것도 남지 않으면 한 번 더 해보고 싶어진다. 실제로 몇 번 더 시도했지만 결과는 같았다.

여기서 멈췄다. 이미 사이트맵이 정상 등록돼 있고 홈 수집 기록도 있었다. 같은 요청을 계속 반복한다고 수집이 빨라질 근거는 없었다. 오히려 요청이 접수됐는지 확인하지 않은 채 “Naver에도 제출 완료”라고 기록하는 쪽이 더 문제였다.

그래서 이번 작업 기록에는 Naver를 성공으로 적지 않았다. 사이트와 사이트맵은 정상, 개별 URL 요청은 접수 여부를 확인하지 못함. 약간 찜찜하지만 이게 그날 확인한 사실에 가장 가까웠다.

Bing은 이상해 보였지만 가장 명확했다

Bing Webmaster Tools를 열었을 때는 반대였다. 첫 화면부터 사이트 속성이 www.rlax.kr로 표시됐다. 현재 RLAX는 www를 쓰지 않으니 잘못 등록된 사이트를 보고 있는 줄 알았다.

안쪽으로 들어가 보니 이야기가 달랐다. Bing은 현재 기준 주소인 https://rlax.kr/wp-sitemap.xml을 성공 상태로 읽고 있었고, 사이트맵 한 곳에서는 45개의 URL을 발견한 것으로 표시했다. 다른 요약 화면에는 알려진 사이트맵 11개와 전체 발견 URL 584개가 함께 나왔다. 오래된 기록이 섞인 숫자처럼 보였지만, 적어도 현재 사이트맵 자체에는 오류와 경고가 없었다.

겉에 붙은 www만 보고 사이트를 다시 등록했으면 오히려 일이 더 복잡해졌을 것이다. 관리자 화면의 사이트 이름보다 실제로 읽고 있는 사이트맵과 기준 주소를 먼저 봐야 했다.

Bing의 URL Submission은 세 곳 중 가장 결과가 분명했다. 홈, 글 목록, 소개, 편집 정책, 최근 글을 포함해 8개 주소를 제출했고 모두 성공으로 남았다. 당일 사용량 8개, 남은 수량 92개라는 숫자도 바로 확인할 수 있었다.

Bing 공식 안내를 다시 읽어보니 수동 제출은 가능하지만 같은 URL을 반복해서 제출한다고 색인이 빨라지는 것은 아니었다. 자주 바뀌는 사이트에는 IndexNow 같은 자동 알림 방식도 권장하고 있었다. 당장은 글이 많지 않은 작은 블로그라 수동 확인으로 충분하지만, 발행량이 늘면 다시 생각해볼 부분이다.

AI에게 브라우저를 맡기고도 남은 일

이번에는 색인 요청 작업 자체를 AI에게 맡겼다. 내가 세 관리자 화면의 메뉴를 일일이 찾아다니는 것보다 빠를 거라고 생각했고, 실제로 그랬다. Google에서 주요 주소를 검사하고, Naver에서 수집 요청을 시도하고, Bing에서 8개 주소를 제출하는 반복 작업은 꽤 잘했다.

그런데 작업이 끝난 뒤 받은 결과는 그대로 글이 될 수 없었다. “사이트맵 성공”, “색인 요청 완료”, “URL 제출 성공” 같은 문장은 얼핏 비슷해 보이지만 서로 다른 상태를 가리켰다. Naver처럼 버튼을 눌렀지만 기록이 남지 않은 경우도 있었다. Bing처럼 사이트 이름은 이상하지만 실제 사이트맵은 정상인 경우도 있었다.

AI는 화면을 빠르게 옮겨 다니고 숫자를 모았다. 그 숫자를 어떤 상태로 기록할지, 무엇을 성공이라고 부르지 않을지는 결국 따로 판단해야 했다.

이 글의 첫 초안을 만들 때도 같은 문제가 생겼다. 작업 기록을 요약해달라고 하니 결과가 꽤 반듯했다. Google, Naver, Bing을 각각 제목으로 나누고, 확인한 것과 다음 할 일을 정리했다. 틀린 내용은 많지 않았지만 읽고 나니 옵시디언에 저장해둔 업무 메모 같았다. 내가 왜 이 일을 시작했는지, 어떤 화면에서 멈칫했는지, 무엇을 성공이라고 부르지 않기로 했는지가 빠져 있었다.

정보는 있었지만 글쓴이는 없었다.

그래서 다시 썼다. AI가 한 일을 감추지도 않고, AI가 정리한 순서를 그대로 글의 구조로 쓰지도 않는 쪽으로. 이 블로그에서 AI는 실제 작업 도구다. 하지만 도구를 썼다는 사실만으로 글이 RLAX의 기록이 되는 것은 아니었다.

발행 버튼 뒤에 생긴 일

이 작업을 하고 나서 새 글을 발행하는 순서가 조금 달라졌다.

전에는 제목과 본문을 고치고 공개 버튼을 누르면 일단 끝이라고 생각했다. 이제는 공개된 주소가 사이트맵에 들어갔는지, 기준 주소가 https://rlax.kr/로 잡혀 있는지, 기존 글에서 새 글로 들어오는 길이 있는지까지 본다. 필요하면 색인 요청을 보내고, 며칠 뒤 실제 상태가 바뀌었는지도 다시 확인해야 한다.

그렇다고 모든 글을 발행할 때마다 세 검색엔진에 달려가 버튼을 누를 생각은 없다. 사이트맵과 내부 링크가 정상이라면 검색엔진이 자연스럽게 발견하는 것이 기본이다. 수동 요청은 중요한 페이지가 빠졌거나, 사이트를 크게 고쳤거나, 오래 방치한 블로그를 다시 깨우는 지금 같은 때에 더 의미가 있다.

이번에 요청한 주소들이 실제 검색 결과에 언제 들어갈지는 아직 모른다. 색인 요청은 노출 보증서가 아니다. 기다려야 하는 부분은 기다리고, 그 사이 검색엔진이 다시 방문했을 때 읽을 만한 글과 연결을 쌓는 수밖에 없다.

색인 요청은 검색엔진에 제출 버튼을 누르는 일보다, 검색엔진이 이 사이트를 어디서 오해하고 있는지 찾아보는 일에 가까웠다.

적자형 블로그를 다시 연 기록이 서버와 기록의 문제였다면, 이번 일은 공개와 발견의 문제였다. 다음에는 이 과정에서 함께 손본 내부 링크와 광고 위치를 따로 남겨보려고 한다. 사이트를 다시 운영한다는 건 글만 더 쓰는 일이 아니라, 글이 발견되고 이어 읽히고 방해받지 않게 만드는 일까지 포함하고 있었다.

7월 7일에 한 일은 결국 세 검색엔진에 주소를 몇 개 제출한 것이 전부다. 그런데 그 작은 작업 덕분에 앞으로 발행 버튼 뒤에서 무엇을 봐야 하는지는 전보다 선명해졌다. 지금의 RLAX에는 그 정도의 운영 감각부터 다시 쌓는 일이 필요했다.

이어 읽기

이 작업은 5년 동안 10달러를 번 적자형 블로그를 다시 열었다에서 이어진다. RLAX가 어떤 경험과 판단을 기록하려는지는 편집 정책과 소개에 적어두었다.

확인 기준: 2026년 7월 7일 Google Search Console, Naver Search Advisor, Bing Webmaster Tools의 RLAX 등록 상태. 기능 설명은 Google Search Central의 사이트맵 안내, Naver Search Advisor, Bing URL Submission 안내를 함께 참고했다.