기업 블로그에서 서비스명 변경이 생기면 과거 글을 한꺼번에 바꾸지 않습니다. 옛 이름이 남은 위치를 먼저 목록으로 만들고, 제목·메타 설명·대체 텍스트·주소·구조화 데이터까지 정한 순서대로 고칩니다. 주소를 바꾼 글에만 영구 리다이렉트를 걸고, 고친 글은 재크롤링을 요청해 반영을 확인합니다.
고치기 전에 어떤 기준을 정해야 하나요?
표기 기준이 없으면 담당자마다 다르게 고칩니다. 그러면 같은 블로그 안에 새 이름, 옛 이름, 두 이름을 함께 적은 표기가 섞입니다. 작업을 시작하기 전에 기준 문서 한 장을 만들고 승인을 받습니다.
- 새 공식 표기: 한글 표기, 띄어쓰기, 영문 표기, 허용하는 약칭을 정합니다.
- 함께 적는 규칙: 옛 이름을 괄호로 함께 적을 위치(첫 언급 한 번 등)와 기간을 정합니다.
- 바꾸지 않는 경우: 변경 전의 출시·수상 같은 당시 사실, 인용문, 보도자료 원문을 어떻게 다룰지 정합니다.
- 변경 기준일: 어느 날부터 새 이름을 쓰는지 날짜로 적습니다.
- 담당자와 완료 기한: 누가 어떤 범위를 언제까지 끝내는지 정합니다.
예를 들어 가상의 ○○ 기업이라면 기준 문서에 아래처럼 적을 수 있습니다.
「2026년 11월 1일부터 ‘옛이름’은 ‘새이름’으로 적습니다. 변경 뒤 고치는 글에는 첫 언급에서만 ‘새이름(옛 이름: 옛이름)’으로 적습니다. 변경 전 사실을 적은 문장은 당시 이름을 그대로 두고 괄호에 새 이름을 붙인다.」
옛 이름을 일정 기간 함께 적는 데는 이유가 있습니다. 옛 이름만 기억하는 독자도 같은 서비스라는 것을 바로 알 수 있습니다.
완료 확인: 기준 문서가 승인되었고 작업자 모두가 같은 문서를 보고 있으면 다음 단계로 넘어갑니다.
옛 이름이 남은 곳은 어떻게 빠짐없이 찾나요?
관리 화면의 본문 검색만으로는 부족합니다. 옛 이름은 화면에 보이지 않는 곳에도 남기 때문입니다. 먼저 검색어 목록을 만듭니다. 옛 이름의 띄어쓰기 변형, 영문 표기, 약칭, 오타까지 모두 넣습니다.
검색할 곳은 세 가지입니다. 블로그 관리 화면의 검색, 데이터베이스나 백업 파일의 텍스트 검색, 사이트 전체를 수집해 HTML 소스를 검색하는 크롤링 도구입니다. 아래 위치를 하나씩 확인합니다.
| 위치 | 확인 방법 | 놓치기 쉬운 이유 |
|---|---|---|
| 글 제목·소제목 | 관리 화면 검색, HTML 소스 검색 | 본문 속 소제목(h2·h3)은 제목 검색에서 빠지고, 검색 결과에 보이는 SEO 제목은 별도 칸에 있는 경우가 있습니다 |
| 메타 설명·공유용 제목 | HTML 소스 검색 | 화면에 보이지 않습니다 |
| 대체 텍스트 | HTML 소스 검색 | 화면에 보이지 않습니다 |
| 그림 속 글자 | 원본 디자인 파일 이름과 이미지 목록을 눈으로 확인 | 그림 안의 글자는 텍스트 검색에 걸리지 않습니다 |
| 글 주소(슬러그) | 주소 목록 내보내기 | 관리 화면의 본문 검색은 주소 문자열을 대상으로 하지 않을 수 있습니다 |
| 태그·카테고리 이름 | 분류 관리 화면 | 본문이 아니라 분류 관리 화면에만 있습니다 |
| 구조화 데이터 | HTML 소스 검색 | 템플릿이나 플러그인 설정에 들어 있습니다 |
| 내부 링크 문구·공통 영역 | 머리말·바닥글·작성자 소개 확인 | 템플릿에 들어 있어 글 단위 검색에서 빠집니다 |
찾은 결과는 한 줄에 위치 하나씩 기록합니다. 아래 양식을 그대로 써도 됩니다.
| 글(주소) | 위치 | 옛 표현 | 새 표현 | 처리 방식 | 확인일 |
|---|---|---|---|---|---|
| (가상) /blog/service-guide | 제목 | 옛이름 사용법 | 새이름 사용법 | 교체 | 수정 뒤 날짜 |
| (가상) /blog/launch-news | 본문 첫 문단 | 옛이름 출시 | 옛이름(현 새이름) 출시 | 함께 적기 | 수정 뒤 날짜 |
완료 확인: 검색어 목록 전체로 다시 검색해 기록 양식에 없는 결과가 0건이면 이 단계를 닫습니다.
어떤 글부터, 어디까지 고쳐야 하나요?
글이 많으면 독자가 많이 보는 곳부터 고칩니다. Search Console 도움말은 실적 보고서 표에서 페이지 탭을 고르면 데이터를 페이지별로 묶어 볼 수 있다고 설명합니다. 클릭 수는 그 보고서의 지표 가운데 하나입니다. 실무에서는 이 페이지별 클릭 수로 작업 순서를 정하는 방법을 권합니다.
| 순서 | 대상 | 먼저 하는 이유 |
|---|---|---|
| 1 | 공통 영역·템플릿·태그와 카테고리 이름 | 한 번 고치면 여러 페이지에 한꺼번에 반영됩니다 |
| 2 | 유입이 많은 글과 서비스 소개 글 | 옛 이름을 보는 독자가 가장 많습니다 |
| 3 | 지금도 유효한 사용법·신청 안내 글 | 독자가 실제로 따라 하는 글입니다 |
| 4 | 지난 소식·행사 후기 | 당시 사실을 적은 글이라 함께 적기로 처리할 수 있습니다 |
어디까지 바꿀지는 문장이 가리키는 시점으로 정합니다. 지금의 서비스를 설명하는 문장은 새 이름으로 바꿉니다. 변경 전의 사실을 적은 문장은 당시 이름을 두고 괄호에 새 이름을 붙입니다. 화면 캡처나 인용문은 원본을 그대로 둡니다. 대신 그림 설명이나 앞 문장에 새 이름을 밝힙니다.
완료 확인: 기록 양식의 모든 줄에 처리 방식이 채워지고 우선순위 1~2번 대상을 모두 고쳤으면 이 단계를 마칩니다.
글 주소에 옛 이름이 들어 있으면 주소도 바꿔야 하나요?
실무에서는 이미 공개된 글의 주소를 되도록 그대로 두는 방법을 권합니다. 주소에 옛 이름이 남아도 독자는 제목과 본문으로 새 이름을 확인합니다. 주소를 바꾸면 리다이렉트와 링크 정리 작업이 함께 생깁니다.
주소를 바꿔야 한다면 Google의 리다이렉트 문서를 기준으로 삼습니다. 이 문서는 영구 리다이렉트(301 또는 308)가 새 주소를 대표 주소로 보이게 하는 신호가 된다고 설명합니다. 서버 측 리다이렉트가 가장 정확하게 해석된다는 설명도 함께 있습니다.
Google의 사이트 이전 문서는 주소가 바뀌는 사이트 이전을 다룹니다. 이 문서는 옛 주소를 최종 주소로 바로 보내 연쇄 리다이렉트를 피하라고 설명합니다. 리다이렉트는 최소 1년 정도, 가능한 한 오래 유지하라고 권합니다. 새 주소마다 자기 자신을 가리키는 canonical(대표 주소 표시)을 두라는 설명도 있습니다. 실무에서는 개별 글 주소를 바꿀 때도 같은 방식을 적용하는 방법을 권합니다.
- 옛 주소와 새 주소를 한 줄씩 짝지은 대응표를 만듭니다.
- 옛 주소마다 대응하는 새 주소로 서버 측 영구 리다이렉트(301 또는 308)를 겁니다. 여러 번 거쳐 가는 연쇄 리다이렉트는 만들지 않습니다.
- 여러 옛 주소를 관련 없는 홈 화면 하나로 몰아 보내지 않습니다.
- 블로그 안 내부 링크를 새 주소로 바꿉니다.
- 사이트맵에는 새 주소를 넣습니다. 새 주소의 글에는 그 주소 자신을 가리키는 canonical을 둡니다.
- 리다이렉트는 최소 1년 이상 유지합니다.
사이트 이전 문서는 중간 규모 사이트의 경우 Google이 옛 주소 대신 새 주소를 보여 주기까지 몇 주 이상 걸릴 수 있다고 설명합니다. 주소를 바꾼 직후 검색 결과에 옛 주소가 보여도 리다이렉트가 정상이면 그대로 지켜봅니다.
완료 확인: 옛 주소를 열면 301 또는 308 상태 코드와 함께 한 번에 새 주소로 넘어가야 합니다. 사이트맵과 내부 링크에서 옛 주소를 검색한 결과가 0건이면 기록 양식에 적습니다.
블로그 이름과 글 제목의 서비스명은 어떻게 맞추나요?
Google의 사이트 이름 문서에 따르면 사이트 이름은 도메인 단위와 하위 도메인 단위 사이트에만 적용되고, 하위 디렉터리에는 적용되지 않습니다. 블로그가 회사 도메인 아래 /blog 같은 하위 디렉터리에 있다면 사이트 이름 작업은 건너뛰고, 아래 글 제목 맞추기만 진행합니다.
블로그가 별도 도메인이나 하위 도메인에 있고 블로그 이름이 서비스명이었다면 사이트 이름도 바꿉니다. 같은 문서는 원하는 이름을 지정할 때 WebSite 구조화 데이터가 가장 중요하다고 설명합니다. 홈페이지의 og:site_name, title 태그, 화면의 주 제목(h1 등) 같은 문구도 함께 고려된다고 합니다.
이 기준에 맞춰 홈페이지의 WebSite 구조화 데이터, og:site_name, title 태그, 화면의 주 제목에 같은 새 이름을 씁니다. 같은 문서는 http와 https, www 유무처럼 홈페이지 버전이 여럿이면 모든 버전에 같은 구조화 데이터를 넣으라고 설명합니다. 약어나 짧은 이름은 alternateName(대체 이름) 속성에 적을 수 있습니다.
개별 글 제목도 함께 맞춥니다. Google의 제목 링크 문서는 title 태그 앞이나 끝에 사이트 이름을 넣는 방법을 권장합니다. 이때 하이픈·콜론·세로선 같은 구분 기호를 씁니다. 검색 결과의 제목 링크는 title 태그만이 아니라 화면의 주 제목, og:title, 연결 문구 등 여러 곳을 바탕으로 만들어집니다. title 태그만 바꾸고 화면의 주 제목에 옛 이름이 남으면 문구가 서로 어긋납니다. 한 글의 title 태그·화면의 주 제목·og:title은 같은 작업에서 함께 바꿉니다.
완료 확인: 별도 도메인 블로그는 홈페이지 HTML 소스에서 구조화 데이터의 name, og:site_name, title 태그, 화면의 주 제목이 모두 같은 새 이름인지 봅니다. 하위 디렉터리 블로그는 고친 글의 title 태그·화면의 주 제목·og:title이 일치하면 이 단계를 닫습니다.
고친 글은 검색엔진에 어떻게 알리고 반영을 확인하나요?
Google에는 두 가지 방법으로 알립니다. 몇 개 주소라면 Search Console의 URL 검사 도구로 색인 생성을 요청합니다. 주소가 많으면 사이트맵을 제출합니다. Google의 재크롤링 문서는 이 요청에 할당량이 있다고 설명합니다. 같은 주소를 여러 번 요청해도 크롤링이 빨라지지 않으며, 색인도 보장되지 않습니다. 크롤링까지 며칠에서 몇 주가 걸릴 수 있다는 설명도 있습니다.
Bing 등 참여 검색엔진에는 IndexNow로 추가·수정·삭제된 주소를 알릴 수 있습니다. IndexNow 시작 안내 문서는 이 방식이 크롤링이나 색인을 보장하지 않는다고 설명합니다. 검색엔진에 변경이 반영되기까지 시간이 걸릴 수 있다고도 밝힙니다. 주소가 전달되었는지는 Bing Webmaster Tools에서 확인하라고 안내합니다.
날짜 표시도 정합니다. Google의 날짜 표시 문서는 날짜가 그 페이지의 게시일이나 수정일이어야 한다고 설명합니다. 화면에 보이는 날짜와 구조화 데이터 날짜도 일치시키라고 합니다. 실무에서는 이름만 바꾼 글에는 수정일을 새로 붙이지 않고, 내용까지 고친 글에만 붙이는 방법을 권합니다. 수정일을 붙인다면 화면 날짜와 dateModified를 같은 날짜로 맞춥니다.
완료 확인: URL 검사 도구에서 마지막 크롤링 날짜가 수정일 이후이고, 크롤링된 페이지에 새 이름이 보여야 합니다. 이어서 검색 결과의 제목 링크에 새 이름이 나오는지 봅니다. 실무에서는 1~2주 간격으로 다시 확인하는 방법을 권합니다. 결과를 기록 양식의 확인일 칸에 적고, 모든 줄이 채워지면 목록을 닫습니다.
정리
- 새 표기, 함께 적는 규칙, 바꾸지 않는 경우를 담은 기준 문서를 승인받습니다.
- 옛 이름의 모든 변형으로 검색어 목록을 만들고, 위치별 기록 양식을 채웁니다.
- 공통 영역과 유입이 많은 글부터 고칩니다. 주소를 바꾼 글에만 301 또는 308 리다이렉트를 걸고 사이트맵과 내부 링크를 새 주소로 정리합니다.
- 글마다 title 태그·화면의 주 제목·og:title을 새 이름으로 맞춥니다. 별도 도메인 블로그라면 홈페이지 구조화 데이터와 og:site_name도 함께 바꿉니다.
- URL 검사와 사이트맵, IndexNow로 변경을 알리고, 확인일을 채워 목록을 닫습니다.
참고 자료
- Provide a site name to Google Search (Google Search Central, 확인일 2026-10-22)
- Move a site with URL changes (Google Search Central, 확인일 2026-10-22)
- Redirects and Google Search (Google Search Central, 확인일 2026-10-22)
- Influencing your title links in search results (Google Search Central, 확인일 2026-10-22)
- Ask Google to recrawl your URLs (Google Search Central, 확인일 2026-10-22)
- Influencing the byline date in Google Search (Google Search Central, 확인일 2026-10-22)
- Performance report (Search results): Overview and basic setup (Search Console 도움말, 확인일 2026-10-22)
- IndexNow Get Started (Microsoft Bing, 확인일 2026-10-22)
