사이트 리뉴얼 사례: 미야자키의 운송 회사 ドーズキャリーサービス ── 기존 사이트에서 무엇을 어떻게 이어받았는가

사이트 리뉴얼에서 가장 두려운 일은, 겉모습이 새로워진 대가로 검색 순위나 문의 경로가 조용히 깨지는 것입니다. 이번에는 미야자키의 운송 회사 「ドーズキャリーサービス」 리뉴얼 사례를 소재로, 디자인보다 먼저 무엇을 확정했는지를 정리합니다.

사이트 리뉴얼이라고 하면 먼저 디자인안이나 홈 페이지의 겉모습부터 이야기가 시작되는 경우가 많습니다. 다만 기존 사이트에 어느 정도 검색 유입이나 백링크가 있으면, 디자인보다 먼저 정해 두지 않으면 되돌리기 어려운 지점이 있습니다. 그것이 URL 설계와, 기존 사이트 정보를 어떻게 이어받을지입니다.

이 기사는 미야자키에서 1인 이사·장거리 배송·냉장 냉동 배송 등을 다루는 운송 회사 「ドーズキャリーサービス」의 사이트 리뉴얼을 소재로, 실제로 어떤 순서로 진행했는지를 정리한 것입니다. 짧은 개요는 ドーズキャリー서비스 구성을 정리한 사례에 있지만, 이 기사에서는 그 내용을 조금 더 깊게 살펴봅니다.

참고로 이 기사에는 접속 수나 문의 수 변화와 같은 효과 측정 수치는 나오지 않습니다. 이번에 정리할 수 있는 것은 「무엇을, 어떤 순서로 실시했는지」라는 사실뿐이며, 효과 수치는 본 기사의 정보원에 포함되어 있지 않기 때문입니다.

이 기사에서 가져갈 수 있는 것은 자사 리뉴얼에 그대로 응용할 수 있는 절차 템플릿입니다. 구체적으로는 URL 전수 조사표와 대응표의 열 구성(2장), 301 리다이렉트 구현 방법과 설정 예(3장), 콘텐츠 유지 체크리스트 만드는 법(4장), 공개 전후 검증 명령과 확인 항목(8장) 네 가지입니다. 「우리 사이트에서도 같은 일을 한다면 무엇을 만들고, 무엇을 확인하면 되는가」라는 관점으로 읽어 주시면 됩니다.

1. 사례 개요 ── Before / After

먼저 전체 그림입니다.

주요 고정 페이지(홈, 서비스 목록, 이사, 냉장 냉동 배송, 당일 배송, 시설 입주 이사, 요금, 회사 정보, FAQ, 문의)와 미야자키·미야코노조·노베오카·니치난·고바야시·휴가·사이토·구시마·에비노 9개 지역 페이지는 리뉴얼 후에도 URL을 그대로 유지합니다. 바뀐 것은 주로 기존 블로그의 의미 없는 URL과, 쓰이지 않던 잔여 스크립트 처리입니다.

참고로 새 사이트 디자인은 디지털청이 공개한 디자인 시스템을 바탕으로 구축했습니다. 디자인을 처음부터 만드는 공정을 생략한 만큼, 그 공수를 이 기사에서 다루는 URL 설계와 콘텐츠 이어받기에 쓸 수 있었습니다. 이 진행 방식의 생각은 왜 小村ソフト는 디지털청 디자인 시스템으로 HP를 만드는가에 정리했습니다.

이 사례의 핵심을 한 마디로 정리하면, 「겉모습을 바꾸기 전에 URL과 콘텐츠 전수 조사를 마친 뒤 착수했다」는 것입니다. 이후 장에서 그 절차를 순서대로 설명합니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 22건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 처음에 한 일은 디자인이 아니라 URL 전수 조사

리뉴얼에 착수할 때 처음 만든 것은 디자인 초안이 아니라, 기존 사이트의 모든 URL을 목록화한 전수 조사표였습니다.

구체적으로는 다음 단위로 빠짐없이 찾아냈습니다.

• 고정 페이지(홈, 서비스 목록, 이사, 냉장 냉동 배송, 당일 배송, 시설 입주 이사, 회사 정보, 개인정보 처리방침, FAQ, 요금, 블로그, 문의)
• 지역 페이지 9개(미야자키·미야코노조·노베오카·니치난·고바야시·휴가·사이토·구시마·에비노)
• 기존 블로그 개별 글(지역 밀착 칼럼부터 1인 이사·장거리 이사 노하우 글까지 100편이 넘음)
• robots.txt나 sitemap.xml, Search Console 소유권 확인용 파일, 기존 폼 전송 스크립트(php/submit.php)처럼 「페이지는 아니지만 공개되어 있는 파일」

전수 조사표의 열 구성은 다음 형태면 충분합니다. 따라 할 때는 이 열부터 시작하세요.

이 전수 조사표가 생긴 뒤에야 「새 사이트에서 이 URL을 어떻게 할지」를 한 건씩 판정하는 대응표(URL 매핑)를 만들 수 있습니다. 대응표의 열은 3열이면 충분합니다. 기존 URL·판정·대상 URL만 두고, 판정 이유는 전수 조사표 쪽 비고에 두면, 대응표를 구현(리다이렉트 정의)으로 기계적으로 변환할 수 있습니다.

이번 대응표에서는 판정을 크게 두 종류로 나눴습니다.

고정 페이지와 지역 페이지, 그리고 현행의 의미 있는 블로그 글 URL은 모두 keep(변경 없음)입니다. 한편 시스템이 자동 채번한 의미 없는 무작위 문자열 URL(/blog/5lmln1lx0x/ 같은 것)이나 post20210721.html 같은 날짜 파일명 URL은, 의미 있는 slug를 가진 새 글 URL로 301 리다이렉트하는 설계로 했습니다.

또 하나, 기존 사이트에 남아 있던 php/submit.php라는 전송 대상 스크립트도 판정 대상이었습니다. 공개된 HTML 전체의 어떤 폼에서도 참조되지 않았고, 실제로 동작하던 문의 경로는 전화·메일·LINE 견적 세 가지뿐임을 확인했기 때문에 「방치된 전송 대상 스크립트」로 판단하고 /contact/로 301하는 처리로 했습니다(이 판단의 경위는 6장에서 자세히 다룹니다).

리다이렉트 설계에서는 다음 두 가지를 규칙으로 지켰습니다.

• 1 hop으로 끝낸다(리다이렉트 연쇄=체인을 만들지 않는다)
• 빌드 시 대상 URL이 실제로 존재하는지 검증하는 장치를 넣는다(존재하지 않는 URL로 301하는 사고를 막는다)

디자인을 검토하기 전에 이 전수 조사와 대응표를 잡아 두면, 이후 구현과 콘텐츠 작성이 「어느 URL에 무엇을 둘지」라는 기반 위에서 진행되므로 재작업이 줄어듭니다. 이 사례에 한정되지 않고, 백링크나 검색 유입이 있는 기존 사이트를 리뉴얼할 때의 기본 절차로서 다른 사례에도 그대로 적용되는 생각입니다.

3. 301 리다이렉트를 어떻게 구현했는가

대응표가 있어도 실제 301 응답으로 바꾸지 않으면 의미가 없습니다. 여기가 가장 「기사에서는 생략되기 쉽지만, 따라 할 때 제일 곤란한」 부분이므로 구체적으로 적습니다.

새 사이트는 정적 사이트 생성 + Cloudflare Pages 구성입니다. 이 구성에서는 리다이렉트를 내는 곳이 두 곳으로 나뉩니다.

이 역할 분담을 처음에 이해하지 못하면 「_redirects에 www 행을 넣었는데 동작하지 않는다」는 식으로 시간을 씁니다. _redirects는 사이트 안 경로에 대해 동작하며, 어떤 호스트 이름으로 온 요청인지에 따른 분기는 할 수 없습니다.

3.1 동일 호스트 안 경로 ── _redirects 파일

Cloudflare Pages에는 빌드 산출물 루트에 _redirects라는 이름의 텍스트 파일을 두면, 그 내용에 따라 리다이렉트를 반환하는 장치가 있습니다. 한 줄에 「원래 경로」「전송 대상」「상태 코드」를 공백으로 구분해서 쓰기만 하면 되는 형식입니다.

/blog/5lmln1lx0x/          /blog/oneroom-mansion-hikkoshi/   301
/blog/post20210721.html    /blog/oneroom-mansion-hikkoshi/   301
/php/submit.php            /contact/                         301

여기서 반드시 끝에 301을 명시하세요. 상태 코드를 생략하면 302(일시적 이동)로 다루어져, 검색 평가 이어받기를 의도한 영구 이전이 되지 않습니다. 정적 리다이렉트 상한은 2,000건이며, 그 규모를 넘으면 Bulk Redirects 쪽으로 옮겨야 합니다.

이번에는 이 _redirects를 손으로 쓰지 않고 빌드 스크립트가 대응표에서 생성하는 구성으로 했습니다. 빌드용 스크립트에 리다이렉트 정의를 배열로 두고, 출력 시 한 줄씩 씁니다. 대략 다음과 같습니다.

// 대응표(기존 URL → 새 URL)를 한곳에 모아 둔다
const redirects = [
  ["/blog/5lmln1lx0x/", "/blog/oneroom-mansion-hikkoshi/"],
  ["/blog/post20210721.html", "/blog/oneroom-mansion-hikkoshi/"],
  ["/php/submit.php", "/ko/contact/"],
];

// dist/_redirects에 「원래 경로 전송 대상 301」 형식으로 쓴다
const body = redirects.map(([from, to]) => `${from} ${to} 301`).join("\n");
await fs.writeFile("dist/_redirects", `${body}\n`);

이렇게 해 두는 이점은 두 가지입니다. 하나는 2장에서 정한 「1 hop으로 끝낸다」「대상 URL이 실제로 존재하는지를 검증한다」는 규칙을 빌드 시 자동 테스트로 보장할 수 있다는 점입니다. 이번에는 생성된 _redirects 내용이 기대와 같은 건수·내용인지 검증하는 테스트를 마련해, 모두 1 hop의 301임을 확인했습니다. 다른 하나는 글 URL을 바꿀 때 대응표 쪽만 고치면 _redirects가 자동으로 따라가므로, 한쪽만 고쳐 깨지는 사고가 나지 않는다는 점입니다.

3.2 호스트 이름이 바뀌는 것 ── Cloudflare의 Redirect Rules

www.douzucarry.com에서 apex(douzucarry.com)로의 301처럼 호스트 이름이 바뀌는 리다이렉트는 Cloudflare 대시보드 쪽에서 설정합니다. 절차는 다음과 같습니다.

1. 대상 존에서 www DNS 레코드가 있고 프록시가 유효(Proxied)한지 확인한다. DNS 레코드가 없으면 요청이 Cloudflare에 도달하지 않습니다.
2. Rules > Redirect Rules > Create rule을 연다.
3. 조건(When)에 「Hostname equals www.douzucarry.com」을 지정한다.
4. 동작(Then)에서 Dynamic redirect를 고르고, 전송 대상 식을 concat("https://douzucarry.com", http.request.uri.path)로 한다. 상태는 301, Preserve query string은 ON.

경로를 그대로 이어받는 식으로 한 것은 www 쪽 각 페이지를 apex의 같은 경로로 1대1로 보내기 위해서입니다. 한편 7장에서 다루는 기존 LP 도메인처럼 내용이 새 사이트의 한 페이지로 통합된 경우에는 반대로 경로를 이어받으면 안 됩니다. 와일드카드로 캡처한 부분을 전송 대상에 붙이면 /refrigerated/foo처럼 존재하지 않는 URL로 301되어 404가 늘고 평가가 한곳으로 모이지 않습니다. 이 경우에는 전송 대상을 고정 URL 한 곳으로 둡니다.

3.3 어느 쪽도 아닌 선택지를 피하는 이유

기존 사이트가 PHP나 Apache로 동작하고 있었다면 .htaccess에 RewriteRule ... [R=301,L]를 쓰는 방법도 있습니다. 기존 환경을 당분간 남긴다는 전제라면 이것이 현실적입니다. 반면 HTML의 <meta http-equiv="refresh">에 의한 전송은 HTTP 상태 코드로는 그대로 200이므로, 301로 다루길 원하는 장면에서는 고르지 마세요. JavaScript의 location.href 치환도 같습니다. 「이전했습니다」를 검색 엔진에 전하려면 서버 쪽이 301을 반환해야 합니다.

4. 콘텐츠를 「빠뜨리지 않기」 위한 유지 체크리스트

URL 설계와 병행한 것이, 기존 사이트에 적혀 있던 정보를 새 사이트에서도 빠짐없이 내고 있는지를 확인하기 위한 콘텐츠 유지 체크리스트 작성입니다.

리뉴얼에서는 디자인을 새로 만드는 과정에서 세세한 메시지 문구와 숫자가 어느새 빠지는 경우가 있습니다. 특히 요금, 영업 시간, 연락처, 강점처럼 「문의 판단에 직결되는 정보」가 빠지면, 겉모습은 좋아졌는데 문의가 줄어드는 사고로 이어질 수 있습니다.

그래서 주요 페이지마다 기존 사이트의 필수 정보를 적어 두었습니다. 일부를 들면 다음과 같습니다.

이 체크리스트를 만든 뒤, 새 사이트 공개 전에 기존 페이지와 새 페이지를 하나씩 대조해 요소가 빠지지 않았는지 확인했습니다. 디자인이 바뀌어도 요금이나 영업 시간, 강점 같은 「판단 근거」가 그대로 이어졌음을, 감이나 기억에 의존하지 않고 목록으로 보장했다는 점이 핵심입니다.

5. 로컬 SEO ── 지역 페이지 9개의 설계

기존 사이트에서 이어받은 페이지 안에는 미야자키·미야코노조·노베오카·니치난·고바야시·휴가·사이토·구시마·에비노라는 9개 지역별 개별 페이지가 있습니다.

이 지역 페이지는 「지명+이사」「지명+배송」처럼 지역명을 포함한 검색 쿼리를 받아 주는 페이지입니다. 운송·이사처럼 상권이 지역에 묶인 서비스에서는, 홈 페이지나 요금 페이지만으로는 다 받지 못하는, 지명을 포함한 검색 수요에 대응하는 역할을 합니다.

URL 대응표를 보면 /area/miyazaki/부터 /area/ebino/까지 9개는 모두 keep(URL 변경 없음)으로 판정되어 있으며, 리뉴얼에서 이 구성 자체는 바꾸지 않았습니다. 더불어 각 지역에 묶인 형태로, 지역의 구체적 지명(예를 들어 미야자키 시내 각 지구나 미야코노조 시내 각 지구 등)을 다룬 블로그 글도 다수 있어, 지역 페이지와 블로그 글이 서로 보완하는 구성입니다.

지역 페이지처럼 「같은 포맷을 지명만 바꿔 양산하는」 유형의 페이지는, 내용이 얇으면 검색 엔진과 독자 모두에게 「같은 페이지의 재사용」으로 보일 위험이 있습니다. 이번 경우에는 지역 페이지 본체에 더해, 지역 안 지구 단위의 상세를 블로그 글 쪽에서 개별적으로 나누어 쓰는 역할 분담을 기존 사이트에서 이어받는 형태로 두었고, 양산 페이지 특유의 「얇음」을 피하는 구성이 이미 갖춰져 있었습니다. 리뉴얼에서는 이 구성을 깨지 않고 URL도 그대로 유지합니다.

6. 흩어져 있던 문의 경로를 모으기

2장에서 다룬 php/submit.php 처리는 문의 경로를 정리하는 점에서도 중요한 판단이었습니다.

기존 사이트를 조사한 결과, 공개된 문의 경로로 실제로 동작하던 것은 다음 세 가지뿐임을 확인했습니다.

• 전화(0120-931-677, 접수 시간 8:00~20:00)
• 메일
• LINE 견적

한편 php/submit.php라는 전송 대상 스크립트 자체는 코드에는 남아 있었으나, 공개된 HTML의 어떤 폼에서도 참조되지 않았습니다. 즉 실제로는 쓰이지 않는 「방치된 스크립트」였습니다. 이를 바탕으로 새 사이트에서는 전화·메일·LINE 견적 세 가지를 /contact/ 페이지에 모으고, php/submit.php로의 접근은 /contact/로 301하는 설계로 했습니다.

문의 경로가 여러 페이지나 스크립트에 흩어져 있으면, 어디가 실제로 쓰이는지 리뉴얼 시점에 보이지 않기 쉽습니다. 이번처럼 「실제로 동작하는 경로는 무엇인가」를 먼저 찾아낸 뒤 모으는 진행은, 홈 페이지·서비스 페이지·문의 페이지의 경로를 다시 보는 일반론으로도 들어맞습니다. 이 생각은 이전에 쓴 문의가 오지 않는 사이트에서, 먼저 고칠 세 곳에서도 다루었으니 함께 참고하세요.

7. 기존 도메인 정리 ── 방치된 LP 도메인의 처리

운송 회사처럼 서비스마다 랜딩 페이지를 따로 만들어 온 회사에서는, 어느새 도메인이 여러 개로 흩어져 있는 경우가 있습니다. 이번 경우에도 다음과 같은 도메인 정리가 필요했습니다.

세 번째만 미대응으로 남은 상태입니다. 이 차이는 다음 8장에서 다루는 공개 전 검증 결과로 확인한 것이며, 「설정했다고 생각한 것」이 아니라 실제로 301이 돌아오는지를 확인했습니다.

특히 세 번째 경우는 교훈으로 중요합니다. 기존 냉장 냉동 배송 LP의 내용(−20℃ 대응 냉동기 탑재 차량, 24시간 365일 대응, 정기 배송·루트 배송 같은 메시지)은 새 사이트의 /refrigerated/에 이식했지만, 기존 도메인 자체가 DNS 만료로 추정되어 이름을 확인할 수 없으므로 기존 도메인에서의 301 리다이렉트를 설정할 수 없습니다. 도메인을 유지·갱신하지 않고 방치하면, 그 도메인에 쌓여 있던 백링크 평가나 브랜드 검색 유입을 어느 날 갑자기 잃을 수 있다는 뜻입니다.

서비스 LP를 별도 도메인으로 운영하는 회사가 리뉴얼을 검토할 때는, 콘텐츠를 어디로 통합할지 정하는 것만이 아니라 기존 도메인의 계약 상태(갱신이 이어지는지, DNS가 살아 있는지)도 함께 확인해 두기를 권합니다. 복구할 수 있을 때 301을 설정할 수 있는지에 따라, 이후 평가를 이어받기 쉬운 정도가 달라집니다.

8. 공개 전 검증과 공개 후에 할 일

새 사이트를 공개하기 전에는 다음과 같은 확인을 했습니다.

• 4장에서 만든 콘텐츠 유지 체크리스트와의 대조(기존 페이지와 새 페이지의 요소가 갖추어져 있는지)
• 301 리다이렉트의 실측 확인(실제로 요청을 보내, 예상대로의 상태 코드와 전송 대상이 돌아오는지)
• Search Console 소유권 확인용 파일이 올바르게 200을 반환할 것
• robots.txt·sitemap.xml·_headers처럼 공개에 필요한 파일이 실제로 공개되어 있을 것(_headers는 Cloudflare Pages 고유 파일이며, _redirects와 같이 빌드 산출물 루트에 두면 응답 헤더를 경로마다 추가할 수 있습니다. 보안 관련 헤더나 캐시 제어를 여기서 모아 지정합니다)

301 실측 확인은 브라우저가 아니라 명령으로 하세요. 브라우저는 리다이렉트를 자동으로 따라가므로, 중간에 302가 끼어 있어도 최종 페이지가 표시되어 알아채지 못합니다. curl -I(헤더만 가져옴. 리다이렉트를 따라가지 않음)이면 돌아온 상태 코드와 Location 헤더를 그대로 확인할 수 있습니다.

# 기존 블로그의 ID 포함 URL이 새 slug URL로 301인지
curl -I https://douzucarry.com/blog/5lmln1lx0x/

# 날짜 파일명의 .html URL도 같이 확인한다
curl -I https://douzucarry.com/blog/post20210721.html

# www로 온 요청이 apex로 301인지(경로가 이어지는지도 본다)
curl -I https://www.douzucarry.com/price/

볼 것은 첫 줄 상태 행이 301인 것과, Location: 값이 대응표의 「대상 URL」과 일치하는 것 두 가지입니다. 여기서 302가 오면 _redirects의 상태 코드 누락, Location이 가리키는 곳이 다시 다른 URL로 전송되면 체인이 생긴 것으로 원인을 나눌 수 있습니다. 대응표의 redirect 행은 모두 이 방법으로 한 건씩 확인합니다.

공개 후에도 할 일이 있습니다.

• sitemap.xml을 Search Console에 다시 제출한다
• URL 검사 도구로, 기존 블로그의 ID 포함 URL이나 날짜 파일명의 .html URL이 예상대로 301인지 개별 확인한다
• 커버리지 리포트에서, 이전에는 404나 색인 밖이었던 기존 URL이 「리다이렉트」로 인식되는지를 수 주에 걸쳐 확인한다

리뉴얼 작업은 「공개하면 끝」이 아니라, 공개 후 리다이렉트가 검색 엔진 쪽에 제대로 인식될 때까지 모니터링해야 비로소 끝난다는 전제로 계획해 두면 안심입니다.

9. 정리 ── 리뉴얼에서 실패하지 않기 위한 일반 규칙

이번 ドーズキャリーサービス 사례에서, 다른 리뉴얼 사례에도 공통으로 들어맞는 생각을 정리하면 다음과 같습니다.

• URL 설계가 먼저, 디자인은 나중. 기존 검색 유입이나 백링크가 있는 기존 사이트에서는, 겉모습을 검토하기 전에 전체 URL 전수 조사와 새 URL로의 대응표(301 매핑)를 확정한다.
• 기존 콘텐츠 전수 조사 없이 공개하지 않는다. 요금·영업 시간·연락처·강점 같은 「판단 근거」는 기존 페이지와 새 페이지를 하나씩 대조하는 체크리스트로 확인한 뒤 공개한다.
• 실제로 쓰이는 경로만 남긴다. 쓰이지 않는 폼이나 전송 대상 스크립트를 찾으면, 실태를 확인한 뒤 살아 있는 경로로 모은다.
• 리다이렉트는 1 hop, 대상 URL의 실제 존재 확인을 세트로 둔다. 체인을 만들지 않고, 존재하지 않는 URL로 보내지 않는 장치를 갖춘다.
• 301을 내는 곳은 두 곳으로 나뉜다. 동일 호스트 안 경로는 빌드 산출물의 설정 파일(Cloudflare Pages라면 _redirects), 호스트 이름이 바뀌는 것은 CDN·DNS 쪽 규칙으로 설정한다. 어느 쪽이든 상태 코드를 명시하고, 공개 전에 curl -I로 한 건씩 실측한다.
• 도메인은 살아 있을 때 정리한다. 서비스 LP용 별도 도메인을 방치하면 DNS 만료로 복구 불가가 되어, 평가를 이어받을 기회 자체를 잃는다.

사이트 리뉴얼은 단순히 디자인을 새로 하는 작업이 아니라, 지금까지 쌓아 온 검색 평가와 문의 경로를 어떻게 이어받을지라는 설계 작업이기도 합니다. 이 사례의 짧은 개요는 ドーズキャリー서비스 구성을 정리한 사례에 정리했으니 함께 보세요.

같은 식으로 URL 설계나 기존 콘텐츠 이어받기가 불안할 때는 홈페이지 제작 상담 안에서 기존 사이트 전수 조사부터 함께 진행할 수 있습니다.

관련 기사

• ドーズキャリー서비스 구성을 정리한 사례
• 왜 小村ソフト는 디지털청 디자인 시스템으로 HP를 만드는가 ── 저렴함과 품질은 양립할 수 있다
• 문의가 오지 않는 사이트에서, 먼저 고칠 세 곳
• 홈페이지 제작
• 문의

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

사이트 리뉴얼은 무엇부터 시작해야 합니까?

디자인안이 아니라, 기존 사이트의 모든 URL을 목록화한 전수 조사표부터 시작합니다. 고정 페이지, 지역 페이지, 블로그 글에 더해 robots.txt나 Search Console 소유권 확인용 파일, 폼 전송 스크립트처럼 「페이지는 아니지만 공개되어 있는 파일」까지 빠짐없이 찾아냅니다. 그다음 URL마다 keep(변경하지 않음)인지 redirect(301 리다이렉트)인지 판정하는 대응표를 만듭니다. 이 기반을 먼저 잡으면 이후 구현과 콘텐츠 작업의 재작업이 줄어듭니다.

리뉴얼에서 검색 순위를 떨어뜨리지 않기 위한 리다이렉트 설계 포인트는 무엇입니까?

고정 페이지나 지역 페이지처럼 의미가 있는 URL은 그대로 유지(keep)하고, 시스템이 자동 채번한 의미 없는 URL만 의미 있는 slug를 가진 새 URL로 301 리다이렉트합니다. 설계 규칙으로는 리다이렉트를 1 hop으로 끝내 체인을 만들지 않을 것, 빌드 시 대상 URL이 실제로 존재하는지 검증하는 장치를 넣어 존재하지 않는 URL로 301하는 사고를 막을 것, 이 두 가지를 지킵니다. 공개 후에는 Search Console에서 리다이렉트가 인식될 때까지 수 주간 모니터링합니다.

리뉴얼 후 문의가 줄어드는 사고는 왜 일어납니까?

디자인을 새로 만드는 과정에서 요금·영업 시간·연락처·강점처럼 문의 판단에 직결되는 정보가 어느새 빠지는 경우가 있기 때문입니다. 대책으로는 주요 페이지마다 기존 사이트의 필수 정보(요금 플랜, 접수 시간, 제공하는 서비스 등)를 적어 둔 콘텐츠 유지 체크리스트를 만들고, 공개 전에 기존 페이지와 새 페이지를 하나씩 대조합니다. 감이나 기억에 의존하지 않고 목록으로 보장하는 것이 핵심입니다.

쓰지 않는 별도 도메인의 LP는 방치해도 문제없습니까?

방치는 위험합니다. 이 사례에서는 냉장·냉동 배송용 기존 LP 도메인이 DNS 만료로 추정되는 이유로 이름을 확인할 수 없었고, 콘텐츠는 새 사이트로 옮긴 뒤에도 기존 도메인에서 301 리다이렉트를 설정할 수 없는 상태였습니다. 도메인을 유지·갱신하지 않고 방치하면 쌓여 있던 백링크 평가나 브랜드 검색 유입을 어느 날 갑자기 잃을 수 있습니다. 리뉴얼을 검토할 때는 기존 도메인의 계약 상태와 DNS가 살아 있는지를 함께 확인하고, 복구할 수 있을 때 301을 설정해야 합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.