사이트 리뉴얼 사례: 미야자키 운송회사 도즈캐리서비스 ── 구 사이트에서 무엇을 어떻게 이어받았는가

사이트 리뉴얼에서 가장 무서운 것은, 겉모습이 새로워진 대신 검색 순위나 문의 유입 경로가 조용히 무너지는 것입니다. 이번에는 미야자키의 운송회사 「도즈캐리서비스」의 리뉴얼 사례를 소재로, 디자인보다 먼저 무엇을 다졌는지를 정리합니다.

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

이 글은 미야자키에서 단신 이사·장거리 배송·냉장냉동 배송 등을 다루는 운송회사 「도즈캐리서비스」의 사이트 리뉴얼을 소재로, 실제로 어떤 절차로 진행했는지를 정리한 것입니다. 간단한 개요는 도즈캐리서비스의 구성을 정리한 사례에 있지만, 이 글에서는 그 내용을 조금 더 자세히 다룹니다.

또한, 이 글에는 접속 수나 문의 수의 변화와 같은 효과 측정 수치는 나오지 않습니다. 이번에 정리할 수 있었던 것은 「무엇을, 어떤 절차로 실시했는가」라는 사실뿐이며, 효과에 관한 수치는 이 글의 정보원에 포함되어 있지 않기 때문입니다.

1. 프로젝트 개요 ── Before / After

먼저 전체적인 그림입니다.

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

참고로 새 사이트의 디자인은, 일본 디지털청이 공개한 디자인 시스템을 토대로 구축했습니다. 디자인을 처음부터 만드는 공정을 줄임으로써, 그만큼의 작업량을 이 글에서 다루는 URL 설계와 콘텐츠 이전 작업에 투입할 수 있었습니다. 이러한 진행 방식에 대한 생각은 왜 코무라소프트는 디지털청 디자인 시스템으로 홈페이지를 만드는가에 정리해 두었습니다.

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

2. 가장 먼저 한 일은 디자인이 아니라 URL 정리

리뉴얼에 착수할 때 가장 먼저 만든 것은 디자인 러프안이 아니라, 구 사이트의 전체 URL을 목록화한 정리표였습니다.

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

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

이 정리표가 완성되어야 비로소 「새 사이트에서 이 URL을 어떻게 할 것인가」를 하나씩 판정하는 대응표(URL 매핑)를 만들 수 있습니다. 이번 대응표에서는 판정을 크게 두 가지로 나눴습니다.

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

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

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

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

디자인을 검토하기 전에 이 정리표와 대응표를 먼저 다져두면, 이후 공정인 구현과 콘텐츠 제작을 「어느 URL에 무엇을 둘 것인가」라는 토대 위에서 진행할 수 있어 재작업이 줄어듭니다. 이는 이 프로젝트에 한정되지 않고, 백링크나 검색 유입이 있는 구 사이트를 리뉴얼할 때의 기본 절차로서 다른 프로젝트에도 그대로 적용되는 사고방식입니다.

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

URL 설계와 병행하여 진행한 것이, 구 사이트에 쓰여 있던 정보를 새 사이트에서도 빠짐없이 노출할 수 있는지 확인하기 위한 콘텐츠 유지 체크리스트 작성입니다.

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

그래서 주요 페이지별로 구 사이트의 필수 정보를 정리했습니다. 일부를 예로 들면 다음과 같은 내용입니다.

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

4. 로컬 SEO ── 지역 페이지 9장의 설계

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

이 지역 페이지들은 「지명+이사」「지명+배송」과 같이 지역명을 포함한 검색어를 받아내기 위해 마련된 페이지입니다. 운송·이사처럼 상권이 지역에 결부되는 서비스에서는, 홈페이지나 요금 페이지만으로는 다 잡아내지 못하는 지명을 포함한 검색 수요에 대응하는 역할을 합니다.

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

지역 페이지처럼 「같은 형식을 지명만 바꿔서 대량으로 만드는」 유형의 페이지는, 내용이 부실하면 검색엔진에게도 독자에게도 「같은 페이지의 재사용」으로 보일 위험이 있습니다. 이번 사례에서는 지역 페이지 본체에 더해, 지역 내 지구 단위의 상세 내용을 블로그 글 쪽에서 개별적으로 나누어 작성하는 역할 분담을 구 사이트에서 그대로 이어받는 형태였기 때문에, 대량 생산 페이지 특유의 「부실함」을 피하는 구성이 이미 갖춰져 있었습니다. 리뉴얼에서는 이 구성을 무너뜨리지 않고 URL도 그대로 유지했습니다.

5. 흩어져 있던 문의 유입 경로의 집약

3장에서 언급한 php/submit.php의 처리는 문의 유입 경로를 정리하는 데에도 중요한 판단이었습니다.

구 사이트를 조사한 결과, 공개되어 있는 문의 유입 경로로서 실제로 기능하고 있던 것은 다음 3가지뿐이라는 것을 확인할 수 있었습니다.

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

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

문의 유입 경로가 여러 페이지와 스크립트에 분산되어 있으면, 실제로 어느 것이 사용되고 있는지가 리뉴얼 시점에 파악하기 어려워지기 쉽습니다. 이번처럼 「실제로 기능하고 있는 경로는 무엇인가」를 먼저 파악한 다음 집약하는 진행 방식은, 홈페이지·서비스 페이지·문의 페이지의 경로를 재검토하는 일반론으로서도 적용됩니다. 이 사고방식은 이전에 작성한 문의가 오지 않는 사이트에서 먼저 고쳐야 할 세 곳에서도 다루고 있으니 함께 참고해 주십시오.

6. 구 도메인 정리 ── 방치된 LP 도메인의 처리

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

특히 세 번째 사례는 교훈으로서 중요합니다. 구 냉장냉동 배송 LP의 내용(−20℃ 대응 냉동기 탑재 차량, 24시간 365일 대응, 정기 배송·경로 배송과 같은 홍보 문구)은 새 사이트의 /refrigerated/로 이전이 끝났지만, 구 도메인 자체가 DNS 실효가 의심되어 이름 해석이 되지 않는 상태이기 때문에 구 도메인으로부터의 301 리다이렉트를 설정할 수 없습니다. 도메인을 유지·갱신하지 않고 방치하면, 그 도메인에 쌓여 있던 백링크 평가나 브랜드 검색 유입을 어느 날 갑자기 잃어버릴 수 있다는 것입니다.

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

7. 공개 전 검증과 공개 후에 해야 할 일

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

• 2장·3장에서 만든 콘텐츠 유지 체크리스트와의 대조(신구 페이지의 요소가 갖춰져 있는지)
• 301 리다이렉트의 실측 확인(실제로 요청을 보내, 예상한 대로의 상태 코드와 전송 대상이 반환되는지)
• Search Console 소유권 확인용 파일이 정상적으로 200을 반환하는 것
• robots.txt·sitemap.xml·_headers와 같이 공개에 필요한 파일들이 실제로 공개되어 있는 것

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

• sitemap.xml을 Search Console에 다시 제출한다
• URL 검사 도구로 구 블로그의 ID가 붙은 URL이나 날짜 파일명의 .html URL이 예상대로 301이 되고 있는지 개별적으로 확인한다
• 커버리지 리포트에서, 이전에는 404이거나 색인에서 제외되어 있던 구 URL이 「리다이렉트」로 인식되는지를 몇 주에 걸쳐 확인한다

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

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

이번 도즈캐리서비스 사례에서, 다른 리뉴얼 프로젝트에도 공통적으로 적용되는 사고방식을 정리하면 다음과 같습니다.

• URL 설계가 먼저, 디자인은 나중. 기존 검색 유입이나 백링크가 있는 구 사이트에서는, 겉모습을 검토하기 전에 전체 URL 정리와 새 URL로의 대응표(301 매핑)를 확정한다.
• 구 콘텐츠 정리 없이 공개하지 않는다. 요금·영업시간·연락처·강점 같은 「판단 근거」는, 신구 페이지를 하나씩 대조하는 체크리스트로 확인한 후 공개한다.
• 실제로 사용되고 있는 경로만 남긴다. 사용되지 않는 폼이나 전송용 스크립트를 발견하면, 실태를 확인한 다음 살아 있는 경로로 집약한다.
• 리다이렉트는 1홉, 대상의 실재 확인을 세트로 한다. 체인을 만들지 않고, 존재하지 않는 URL로 보내지 않는 장치를 갖춘다.
• 도메인은 살아 있을 때 정리한다. 서비스 LP용 별도 도메인을 방치하면 DNS 실효로 복구 불가능해져, 평가를 이어받을 기회 자체를 잃게 된다.

사이트 리뉴얼은 단순히 디자인을 새롭게 하는 작업이 아니라, 지금까지 쌓아온 검색 평가와 문의 유입 경로를 어떻게 이어받을 것인가 하는 설계 작업이기도 합니다. 이 사례의 간단한 개요는 도즈캐리서비스의 구성을 정리한 사례에 정리해 두었으니 함께 참고해 주십시오.

마찬가지로 URL 설계나 기존 콘텐츠 이전에 불안함이 있으시다면, 홈페이지 제작 상담을 통해 구 사이트 정리부터 함께 진행할 수 있습니다.

관련 글

• 도즈캐리서비스의 구성을 정리한 사례
• 왜 코무라소프트는 디지털청 디자인 시스템으로 홈페이지를 만드는가 ── 저렴함과 품질은 양립할 수 있다
• 문의가 오지 않는 사이트에서 먼저 고쳐야 할 세 곳
• 홈페이지 제작
• 문의하기

관련 기사

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

관련 토픽

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

자주 묻는 질문

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

사이트 리뉴얼은 무엇부터 시작해야 하나요?

디자인안이 아니라, 구 사이트의 전체 URL을 목록화한 정리표부터 시작합니다. 고정 페이지, 지역 페이지, 블로그 글은 물론, robots.txt나 Search Console 소유권 확인용 파일, 폼 전송 스크립트 같은 「페이지는 아니지만 공개되어 있는 파일」까지 빠짐없이 찾아냅니다. 그 다음, URL별로 keep(변경하지 않음)인지 redirect(301 리다이렉트)인지를 판정하는 대응표를 만듭니다. 이 토대를 먼저 다져 두면 이후 공정인 구현과 콘텐츠 제작에서의 재작업이 줄어듭니다.

리뉴얼로 검색 순위가 떨어지지 않게 하기 위한 리다이렉트 설계의 핵심은 무엇인가요?

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

리뉴얼로 문의가 줄어드는 사고는 왜 일어나나요?

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

사용하지 않는 별도 도메인의 LP는 방치해도 문제없나요?

방치는 위험합니다. 이 사례에서는 냉장냉동 배송용 구 LP 도메인이 DNS 실효가 의심되는 상태로 이름 해석이 되지 않아, 콘텐츠는 새 사이트로 이전했음에도 구 도메인으로부터의 301 리다이렉트를 설정할 수 없는 상태가 되어 있었습니다. 도메인을 유지·갱신하지 않고 방치하면, 그동안 쌓인 백링크 평가나 브랜드 검색 유입을 어느 날 갑자기 잃어버릴 수 있습니다. 리뉴얼을 검토할 때는 구 도메인의 계약 상태와 DNS가 살아 있는지를 함께 확인하고, 복구할 수 있는 동안에 301을 설정해 두어야 합니다.

저자 프로필

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

Go Komura

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

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