SEO 유지보수: 한 번 개선한 설정이 그대로 남지 않는 이유

리뉴얼을 마치고 검색 관련 점검까지 끝냈습니다. 여섯 달 뒤 자연 검색 유입이 내려갑니다. 그동안 아무도 SEO 설정을 건드리지 않았습니다. 담당자는 "우리가 뭘 잘못했나"를 찾지만, 로그를 뒤져도 그런 작업 기록은 나오지 않습니다.

이런 상황이 반복되는 이유는 개선을 유지되는 상태로 이해했기 때문입니다. SEO 유지보수를 선택 사항으로 남겨두는 판단도 같은 이해에서 나옵니다. 검색 조건은 사이트 안에만 있지 않습니다. 사이트가 한 축, 검색엔진이 한 축, 측정 기준이 또 한 축이고, 세 축은 서로의 사정을 고려하지 않고 각자 움직입니다. 세 축 중 하나만 움직여도 처음 맞춰둔 정합이 어긋납니다.

이 글은 그 세 축이 실제로 어떻게 움직였는지를 구글의 공개된 변경 이력으로 확인하고, 산업별로 먼저 어긋나는 지점과 점검 주기를 정리합니다. 지속 관리가 필요하지 않은 조건도 함께 적었습니다. 모든 조직에 관리 계약이 필요한 것은 아닙니다.

개선은 상태가 아니라 시점의 결과다#

진단 보고서는 특정 날짜의 사이트를 그 시점의 검색 기준으로 본 결과입니다. 개선 작업이 끝난 순간의 정합은 두 가지 전제 위에 서 있습니다. 사이트가 그대로 있을 것, 그리고 검색 기준이 그대로 있을 것. 실제로는 둘 다 유지되지 않습니다.

검색엔진 쪽 변화만 봐도 그렇습니다. 구글의 코어 업데이트 안내는 구글이 검색 알고리즘과 시스템에 연간 여러 차례 큰 변경을 적용한다고 설명합니다. 같은 문서는 업데이트가 완료된 뒤 최소 일주일을 기다려 서치콘솔 데이터를 분석하라고 권하고, 가시성 회복에는 수개월이 걸릴 수 있다고 적습니다.

여기서 나오는 실무적 결론은 "몇 개월마다 다시 진단해야 한다"가 아닙니다. 질문을 바꿔야 합니다. 무엇이 움직였을 때 다시 봐야 하는가. 세 축을 나눠 보면 각 축마다 신호가 다릅니다.

사이트가 바뀐다: 배포가 검색 설정을 덮어쓴다#

검색 조건은 한 파일에 모여 있지 않습니다. canonical은 레이아웃 템플릿에, robots 메타는 페이지 컴포넌트에, 리디렉션 규칙은 서버나 CDN 설정에, 사이트맵은 빌드 스크립트에, 구조화 데이터는 각 상세 페이지에 흩어져 있습니다. 이 위치들은 모두 일반적인 기능 개발이 손대는 자리입니다.

그래서 검색 설정이 사라지는 일은 사고가 아니라 정상적인 배포의 부작용으로 일어납니다. 자주 보이는 형태는 이렇습니다.

스테이징에 걸어둔 noindex가 운영 배포에 함께 넘어갑니다. 환경 변수로 분기하지 않고 템플릿에 직접 적어둔 경우에 특히 그렇습니다. 컴포넌트를 교체하다 h1이 사라집니다. 반대로 한 페이지에 둘이 생기기도 합니다. 라우팅을 정리하면서 이전 경로가 리디렉션 없이 404가 되고, CMS를 옮기면서 canonical이 절대 URL에서 상대 경로로 바뀝니다.

배포 전
GET /guide/onboarding        200   canonical: https://example.com/guide/onboarding
GET /docs/getting-started    301   location: /guide/onboarding

배포 후
GET /guide/onboarding        200   canonical: /guide/onboarding
GET /docs/getting-started    404

이 두 변화는 릴리스 노트에 남지 않습니다. 기능은 정상이고 화면도 정상이기 때문입니다.

렌더링 방식을 바꿀 때는 영향이 더 큽니다. 구글의 자바스크립트 SEO 기본 가이드는 Googlebot이 크롤링, 렌더링, 색인 세 단계로 페이지를 처리하며, 렌더링 대기열에서 몇 초보다 훨씬 오래 기다릴 수 있다고 설명합니다. 같은 문서는 클라이언트 라우팅을 쓰는 단일 페이지 앱이 존재하지 않는 콘텐츠에 올바른 HTTP 상태 코드를 돌려주기 어렵고, 그래서 soft 404가 생긴다는 문제도 지적합니다. 화면에는 "찾을 수 없습니다"가 뜨는데 서버는 200을 반환하는 상태입니다.

검색엔진이 바뀐다: 지원하던 표시가 사라진다#

사이트를 전혀 건드리지 않아도 결과가 사라지는 축입니다. 구글이 지원하던 검색 결과 표시를 종료하면, 그 표시를 위해 넣은 마크업은 남아 있는데 결과만 없어집니다.

지원 종료는 예외적인 사건이 아닙니다. 공개된 발표와 변경 이력만 모아도 이렇습니다.

2020-01   data-vocabulary.org 마크업 지원 종료
2023-06   사이트맵 ping 엔드포인트 지원 종료
2023-08   HowTo 리치 결과 종료, FAQ 리치 결과 노출 대상 축소 발표
2024-10   사이트링크 검색창 지원 종료
2026-01   연습문제 구조화 데이터 문서 제거
2026-05   FAQ 리치 결과 검색 결과 표시 종료

각각 근거가 있습니다. data-vocabulary 지원 종료는 2020년 1월 발표였습니다. 사이트맵 ping 엔드포인트 종료는 2023년 6월입니다. HowTo와 FAQ 리치 결과 변경 발표에서 구글은 HowTo 리치 결과를 더 이상 표시하지 않고, FAQ 리치 결과는 잘 알려진 정부와 보건 기관 사이트에만 노출하겠다고 밝혔습니다. 사이트링크 검색창은 2024년 10월에 사라졌습니다. 그리고 구글 검색 센터 변경 이력에 따르면 FAQ 리치 결과는 2026년 5월 7일부터 검색 결과에 표시되지 않으며, 2026년 6월 15일에 관련 문서가 제거되었습니다.

이 목록에서 읽어야 할 것은 마크업을 넣은 팀이 판단을 잘못했다는 이야기가 아닙니다. 그 시점에는 올바른 작업이었습니다. 다만 검색 결과 표시에는 지원 기간이 있고, 그 기간은 사이트가 결정하지 않습니다.

정확하게 구분할 점이 하나 있습니다. 구글은 이런 구조화 데이터 지원 종료가 페이지의 순위 결정 방식을 바꾸지는 않는다고 설명합니다. 사라지는 것은 검색 결과에서의 표시 형태입니다. 그래도 클릭률과 노출 면적은 달라질 수 있으므로, 순위 하락이 아니라는 이유로 확인 없이 넘길 일도 아닙니다.

실무에서 필요한 대비는 재작업이 아니라 목록입니다. 어느 템플릿에 어떤 구조화 데이터 타입이 붙어 있는지 적어둔 문서가 없으면, 종료 발표를 읽어도 우리 사이트의 영향 범위를 산정할 수 없습니다. 붙일 때 기록해야 뗄 때 찾을 수 있습니다.

측정 기준이 바뀐다: 통과하던 지표가 다시 미달이 된다#

세 번째 축은 사이트도 검색 결과도 아니고, 그것을 재는 자입니다. 지표의 정의가 교체되면 코드를 한 줄도 바꾸지 않은 사이트의 평가가 달라집니다.

가장 분명한 사례가 응답성 지표 교체입니다. 구글은 2023년 5월 INP를 코어 웹 바이탈로 도입한다고 발표했고, INP는 2024년 3월 12일 정식 코어 웹 바이탈이 되면서 FID를 대체했습니다. 같은 발표에 따르면 FID는 교체 시점에 서치콘솔에서 즉시 제거되었습니다.

FID는 첫 입력에 대한 지연만 측정했습니다. INP는 페이지 수명 전체의 상호작용 응답성을 봅니다. 측정 대상이 다르므로, FID 기준으로 통과하도록 맞춘 작업이 INP에서도 같은 결과를 낸다고 보장할 수 없습니다. 사이트는 그대로인데 성적표의 항목이 바뀐 상황입니다.

도구 쪽 변화는 더 조용히 지나갑니다. 앞에서 본 사이트맵 ping 종료가 그렇습니다. 배포 파이프라인에 사이트맵 갱신 알림 단계를 넣어둔 팀에서는 그 호출이 의미를 잃었는데, 파이프라인은 계속 성공으로 표시됩니다. 실패하지 않고 무효가 되는 변화는 정기 점검이 아니면 발견되지 않습니다.

측정 창 자체도 유한합니다. 서치콘솔 성과 보고서의 기본 보기는 최근 3개월입니다. 유입이 언제부터 어떻게 내려갔는지 판단하려면 그 시점의 기준값을 어딘가에 남겨둬야 합니다. 개선 직후의 색인 URL 수, 리디렉션 응답, 주요 템플릿의 렌더 결과를 기록하지 않으면, 나중에는 무엇과 비교해야 하는지부터 알 수 없습니다.

기획 단계에서 정해진 것은 나중에 되돌리기 비싸다#

지금까지가 오픈 이후의 이야기라면, 관리 비용을 가장 크게 줄이는 개입 시점은 그 앞입니다. 설계 단계에서 결정되고 오픈 후에는 사실상 고정되는 항목이 있습니다.

기획 단계에서 확정하면 이후 비용이 크게 줄어드는 것
  URL 구조와 슬러그 규칙, 끝 슬래시 처리
  대표 호스트와 프로토콜
  렌더링 방식(서버 렌더링, 사전 생성, 클라이언트 렌더링)과 템플릿별 적용 범위
  다국어와 지역 구분 방식
  카테고리 분류 체계와 계층 깊이
  페이지 생성 주체(CMS, 피드, 관리자 입력)와 색인 대상 판정 규칙

이 항목들을 오픈 후에 바꾸면 작업의 성격이 달라집니다. URL 구조 변경은 개선이 아니라 사이트 이동입니다. 구글의 사이트 이동 가이드는 리디렉션을 가능한 한 오래, 일반적으로 최소 1년 이상 유지하라고 권고하고, 사용자 관점에서는 무기한 유지를 검토하라고 적습니다. 같은 문서는 이동 후 서치콘솔, 서버 로그, 웹 분석으로 모니터링할 것과, 이동 기간에 검색 가시성이 일시적으로 변동할 수 있다는 점도 설명합니다.

즉 오픈 후 URL을 정리하기로 결정하는 순간, 1년 이상 유지해야 하는 리디렉션 자산과 그 기간의 모니터링 업무가 함께 생깁니다. 기획서 한 줄로 끝날 결정이 운영 부담으로 넘어갑니다.

오픈 검수 항목에 검색 조건이 들어 있는지도 이 단계에서 정해집니다. 검수 목록에 없으면 아무도 오픈 당일에 확인하지 않습니다. 색인은 즉시 일어나지 않으므로, 문제는 검수가 끝나고 몇 주가 지난 뒤에 유입 지표로 나타납니다. 그때는 원인 후보가 이미 여러 개입니다.

산업별로 먼저 무너지는 지점이 다르다#

같은 원인이 모든 조직에서 같은 순서로 드러나지는 않습니다. 운영 구조가 다르기 때문입니다.

SI 구축 사업#

계약이 오픈과 함께 끝나는 구조가 문제의 출발점입니다. 검색 관련 문제는 오픈 직후가 아니라 재수집이 진행되는 수 주에 걸쳐 드러나는데, 그 시점에는 구축 인력이 이미 다음 프로젝트에 있습니다. 하자보수 기간이 남아 있어도 "기능 결함"의 정의에 색인 이탈이 들어가지 않으면 협의가 길어집니다.

인수인계 문서도 자주 비어 있습니다. 리디렉션 맵, canonical 생성 규칙, 사이트맵을 만드는 주체, 색인 대상 판정 로직이 문서에 없으면 운영팀은 근거를 모르는 설정을 그대로 물려받습니다. 다음 리뉴얼에서 같은 문제가 반복되는 이유가 여기 있습니다.

커머스#

상품의 생명주기가 그대로 URL의 생명주기입니다. 품절, 단종, 시즌 종료가 매주 발생하고, 그때마다 페이지를 어떻게 처리할지 규칙이 필요합니다. 규칙이 없으면 단종 상품이 계속 200으로 남거나, 반대로 재입고될 상품이 404가 됩니다.

필터와 정렬은 URL 수를 곱합니다. 구글의 패싯 내비게이션 문서는 패싯 내비게이션이 사이트 소유자가 보고하는 과잉 크롤링 문제의 가장 흔한 원인이라고 명시합니다. 크롤러가 불필요한 URL을 확인하는 데 시간을 쓰면 새로 올라온 유용한 URL의 발견이 늦어진다는 설명도 함께 있습니다. 크롤링 가이드의 중복 URL 정리 권고와 커머스 URL 구조 기준을 함께 봐야 합니다. 이 조합은 카테고리를 신설할 때마다 다시 확인해야 하는 항목입니다.

대기업#

여러 팀과 여러 대행사가 같은 도메인에 각자 배포합니다. 브랜드 사이트, 채용, IR, 뉴스룸, 캠페인 페이지가 서로 다른 스택 위에 있고 배포 주기도 다릅니다. 한 팀의 릴리스가 다른 팀의 검색 설정을 덮는 상황이 조직도상으로는 보이지 않습니다.

캠페인마다 서브도메인이나 별도 도메인을 만드는 관행도 누적됩니다. 종료된 캠페인의 호스트가 계속 응답하면 중복과 노후 콘텐츠가 함께 남습니다. 서치콘솔 속성 관리 자체도 업무입니다. 담당자가 바뀌면서 접근 권한이 유실되면, 문제를 확인할 데이터부터 사라집니다.

중소기업#

제작을 외부에 맡기고 유지보수 계약은 두지 않는 경우가 많습니다. 이 구조에서는 CMS와 플러그인 업데이트가 주요 변경 원인이 됩니다. 테마를 갱신하면서 메타 태그 설정이 초기값으로 돌아가거나, 플러그인을 교체하면서 사이트맵 생성 주체가 둘이 되는 식입니다.

도메인과 인증서 만료도 실제로 발생합니다. HTTPS 연결은 HTTP 응답을 받기 전에 성립해야 하므로, 인증서가 만료되면 걸어둔 리디렉션에 도달하지도 못합니다. 이 문제는 www non-www 리디렉션 정리에서 다룬 호스트 정합 문제와 같은 지점에서 만납니다.

자영업#

사이트보다 영업 정보가 먼저, 더 자주 바뀝니다. 영업시간, 임시 휴업, 주소, 전화번호, 취급 품목입니다. LocalBusiness 구조화 데이터는 openingHoursSpecification으로 영업시간을 적고 validFrom과 validThrough로 기간 한정 휴업을 표기할 수 있게 해줍니다. 적어둔 값은 바뀔 때마다 고쳐야 합니다.

관리 대상 페이지 수가 적어 점검 주기는 길어도 됩니다. 대신 정확성 요구는 더 높습니다. 기술적 결함은 유입을 줄이지만, 잘못된 영업시간은 찾아온 방문을 실패로 만듭니다.

지속 관리가 필요하지 않은 경우#

검색이 사업의 유입 경로가 아니라면 이 글의 권고는 적용되지 않습니다. 다음 조건에서는 지속적인 SEO 관리에 예산을 쓸 이유가 약합니다.

수주가 입찰과 지명으로 이뤄지는 B2B와 관급 사업, 로그인 뒤에서만 동작하는 내부 시스템과 사내 도구, 계정 발급이 영업 접촉으로만 이뤄지는 서비스가 여기 해당합니다. 검색 수요 자체가 아직 없는 신규 카테고리도 마찬가지입니다. 이 경우에는 검색 조건을 다듬기보다 수요를 만드는 활동이 먼저입니다.

다만 이런 조직에도 남는 최소 항목이 있습니다. 도메인과 인증서의 만료 관리, 검색 결과에 노출되면 안 되는 영역이 실제로 차단되어 있는지 확인, 상호와 연락처처럼 외부에서 검색될 정보의 정확성입니다. 이것은 SEO 관리라기보다 기본 운영에 속합니다.

판정을 먼저 해야 합니다. 자연 검색이 현재 유입에서 차지하는 비중, 같은 시장의 경쟁사가 검색으로 발견되는지, 우리 제품이나 서비스를 설명하는 검색어에 실제 수요가 있는지를 확인한 뒤에 관리 수준을 정합니다.

SEO 유지보수 주기를 만드는 최소 구성#

필요하다고 판정했다면, 다음 단계는 별도 프로젝트를 만드는 것이 아닙니다. 이미 돌아가는 배포와 운영 흐름에 점검 항목을 얹는 편이 유지됩니다.

배포할 때마다 (자동화 대상)
  운영 도메인의 robots 메타와 robots.txt에 의도하지 않은 차단이 없는지
  canonical이 자기 자신을 가리키는 절대 URL인지
  삭제되거나 이동한 경로에 리디렉션이 있고 한 번에 끝나는지
  주요 템플릿의 렌더 후 HTML에 본문과 h1이 있는지

월 단위
  색인 상태 변화와 새로 생긴 제외 사유
  4xx와 5xx, 리디렉션 체인의 증가
  사이트맵에 담긴 URL과 실제 색인 대상의 차이

분기 단위
  구글 검색 센터 변경 이력과 우리 사이트가 쓰는 기능의 대조
  구조화 데이터 자산 목록 갱신
  코어 웹 바이탈 필드 데이터 재확인
  기준값 기록 갱신(색인 URL 수, 주요 템플릿 응답, 대표 URL 표본)

주기의 숫자는 권고이고 표준이 아닙니다. 배포가 잦고 URL이 많은 사이트라면 배포 시점 검사에 더 많이 넣고 월 단위 항목을 줄이는 편이 낫습니다. 반대로 몇 달에 한 번 콘텐츠만 추가하는 사이트에서 월 단위 점검을 만들면 지켜지지 않습니다.

배포 시점 검사를 자동화하는 것이 가장 효율이 높습니다. 세 축 중에서 가장 자주 움직이는 것이 사이트이고, 그 변경은 릴리스라는 분명한 시점을 갖기 때문입니다. 검색엔진과 측정 기준의 변화는 시점을 예고 없이 정하므로, 정기적으로 읽는 쪽이 맞습니다.

SEO 유지보수는 같은 작업의 반복이 아니다#

SEO 유지보수를 매달 같은 체크리스트를 다시 훑는 일로 설계하면 몇 달 안에 형식만 남습니다. 실제로 하는 일은 세 축 중 무엇이 움직였는지 확인하고, 움직인 축에 맞는 확인만 하는 것입니다. 배포가 있었다면 사이트를 보고, 구글 발표가 있었다면 우리가 쓰는 기능과 대조하고, 지표 정의가 바뀌었다면 기준값을 다시 잡습니다.

디지털 채널이 사업 경로에 있는 조직이라면 이 관리는 기획 단계부터 시작됩니다. URL 구조와 렌더링 방식을 정할 때 이후 운영 부담이 함께 결정되고, 오픈 검수 항목에 검색 조건을 넣을지 말지가 문제 발견 시점을 좌우합니다. 관리 비용은 오픈 후에 아끼기 어렵습니다.

지금 사이트에서 세 축 중 무엇이 이미 어긋나 있는지 확인하려면, 전체 URL을 응답 코드와 canonical, 렌더 결과 기준으로 한 번 수집해 기준값을 만드는 작업부터 필요합니다. 이탈 지점을 판정하는 방법은 구글 색인 문제 진단에서, 진단 범위와 배포 후 검증 방식은 테크니컬 SEO 진단과 개선에서 확인할 수 있습니다.