網站改版案例：宮崎運輸公司 Douzu Carry Service ── 從舊網站繼承了哪些內容、又是如何繼承的

網站改版最可怕的地方，在於外觀變新的同時，搜尋排名或問詢動線卻在不知不覺間悄悄壞掉。 這次以宮崎運輸公司「Douzu Carry Service」的改版案為題材，整理出在設計之前先確立了哪些事。

提到網站改版，話題往往先從設計草案或首頁外觀開始談起。 但如果舊網站已經有一定的搜尋流量或反向連結，有些事必須在設計之前先決定好，否則之後很難回頭修正。那就是 URL 設計，以及該如何繼承舊網站的資訊。

本文以宮崎經營單身搬家、長途配送、冷藏冷凍配送等業務的運輸公司「Douzu Carry Service」的網站改版為題材，整理實際採用的執行步驟。簡要的概要可參考整理 Douzu Carry Service 網站結構的案例，本文則再進一步深入說明其中的細節。

另外，本文不會出現造訪人數或問詢件數變化之類的成效數據。這次能整理出來的，僅限於「做了什麼、以什麼步驟執行」這項事實，成效數據並不在本文的資料來源之中。

1. 案件概要 ── Before / After

先看整體概況。

主要固定頁面(首頁、服務總覽、搬家、冷藏冷凍配送、當日配送、機構入住搬遷、價格、公司資訊、FAQ、聯絡我們)以及宮崎、都城、延岡、日南、小林、日向、西都、串間、飯野9個地區頁面，改版後URL都維持不變。改變的主要是舊部落格沒有意義的URL，以及沒在使用卻留下來的殘留腳本的處理方式。

另外，新網站的設計，是以日本數位廳公開的設計系統為基礎建構的。省去從零開始設計的工序，把省下來的工時，投入到本文所談的URL設計與內容繼承工作上。這個做法的想法整理在小村軟體為什麼用日本數位廳設計系統做網站 ── 便宜和品質可以兼顧一文中。

這個案例的重點，一句話來說，就是「在改變外觀之前，先完成URL與內容的盤點才動手」。以下各章依序說明其步驟。

2. 最先做的不是設計，而是URL盤點

改版開始時，最先製作的不是設計草案，而是把舊網站所有URL列出來的盤點表。

具體而言，以下列單位不遺漏地一一列出：

• 固定頁面(首頁、服務總覽、搬家、冷藏冷凍配送、當日配送、機構入住搬遷、公司資訊、隱私權政策、FAQ、價格、部落格、聯絡我們)
• 9張地區頁面(宮崎、都城、延岡、日南、小林、日向、西都、串間、飯野)
• 舊部落格個別文章(從地區密著型專欄，到單身搬家、長途搬家know-how文章，共超過100篇)
• robots.txt、sitemap.xml、Search Console所有權驗證檔案、舊表單送出腳本(php/submit.php)等「不是頁面但仍公開存取的檔案」

要有這份盤點表才能進一步製作「新網站中這個URL該怎麼處理」逐一判定的對照表(URL mapping)。這次的對照表中，大致把判定分成兩類。

固定頁面、地區頁面，以及目前有意義的部落格文章URL，全部都是keep(不變更)。另一方面，系統自動編號、沒有意義的隨機字串URL(例如/blog/5lmln1lx0x/)，以及像post20210721.html這種日期檔名的URL，則設計成301轉址到具有有意義slug的新文章URL。

還有一項判定對象，是舊網站中殘留的送出用腳本php/submit.php。經確認，公開的HTML中沒有任何表單參照這個腳本，實際上有在運作的問詢動線只有電話、電子郵件、LINE估價這3種，因此判定為「殘留的送出用腳本」，處理方式是301到/contact/(這項判斷的來龍去脈，會在下一章和第5章詳細說明)。

在轉址設計上，貫徹了以下兩項規則：

• 以1個跳轉完成(不建立轉址的連鎖=不做轉址鏈)
• 在建置時加入驗證機制，確認目的地URL確實存在(避免把301導向不存在的URL這種事故)

在考慮設計之前先把這份盤點表與對照表確立好，後續的實作與內容製作，就能建立在「哪個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的存取設計為301到/contact/。

問詢動線一旦分散在多個頁面或腳本上，到了改版的時間點，往往很難看清楚哪個管道實際上有在使用。像這次這樣，先找出「實際在運作的動線是哪些」再進行整合的做法，作為檢視首頁、服務頁面、問詢頁面之間動線的一般性原則，也同樣適用於其他案子。這個想法在先前寫過的沒有諮詢進來的網站，先要改的三個地方一文中也有談到，歡迎一併參考。

6. 舊網域的整理 ── 被放置不管的LP網域

像運輸公司這樣針對每個服務分別製作登陸頁的公司，網域有時會在不知不覺間分散到多個地方。這次的案例也需要整理以下這些網域。

特別是第三個案例，是很重要的教訓。舊冷藏冷凍配送LP的內容(−20℃冷凍機搭載車、24小時365天對應、定期班次・路線配送等訴求)已經移植到新網站的/refrigerated/，但由於舊網域本身疑似DNS失效而無法解析名稱，因此無法從舊網域設定301轉址。也就是說，若不維護、不續約網域就放著不管，某一天可能會突然失去該網域長年累積下來的反向連結評價與品牌詞搜尋流量。

如果公司是用其他網域來營運服務用登陸頁，考慮改版時，建議不只決定內容要整合到哪裡，也同時確認舊網域的合約狀態(是否持續續約、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. 總結 ── 改版不失敗的一般原則

從這次Douzu Carry Service的案例中，整理出同樣適用於其他改版案子的想法，如下：

• URL設計在先，設計在後。 對於已有搜尋流量或反向連結的舊網站，在考慮外觀之前，先確立完整的URL盤點以及對應到新URL的對照表(301 mapping)。
• 沒有盤點舊內容不能上線。 價格、營業時間、聯絡方式、優勢這類「判斷依據」，要用逐一比對新舊頁面的檢查清單確認後才能上線。
• 只留下實際在使用的動線。 發現沒在用的表單或送出腳本時，先確認實際狀況，再整合到還活著的動線上。
• 轉址要以1個跳轉，加上目的地是否存在的驗證作為一組。 不建立轉址鏈，並具備不會導向不存在URL的機制。
• 網域要在還活著的時候整理。 若放著服務用的其他網域不管，一旦DNS失效就無法復原，連帶失去繼承評價的機會。

網站改版不只是把設計改新而已，也是一項設計工作：思考該如何繼承過去累積下來的搜尋評價與問詢動線。這個案例的簡要概述整理在整理 Douzu Carry Service 網站結構的案例中，歡迎一併參考。

如果您同樣對URL設計或既有內容的繼承感到不安，可以在網站建置的諮詢中，從舊網站的盤點開始一起進行。

相關文章

• 整理 Douzu Carry Service 網站結構的案例
• 小村軟體為什麼用日本數位廳設計系統做網站 ── 便宜和品質可以兼顧
• 沒有諮詢進來的網站，先要改的三個地方
• 網站建置
• 聯絡我們

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

常見問題

整理諮詢這個主題時常見的問題。

網站改版該從什麼開始著手？

不是設計草案，而是先做一份把舊網站所有 URL 列出來的盤點表。除了固定頁面、地區頁面、部落格文章之外，連 robots.txt、Search Console 的所有權驗證檔案、表單送出用的腳本這類「不是頁面但仍公開存取」的檔案，也要一項不漏地列出。接著針對每個 URL，判定是 keep(不變更)還是 redirect(301 轉址)，做成對照表。先把這個基礎打好，之後的實作與內容製作階段就能減少返工。

為了在改版時不讓搜尋排名下滑，轉址設計上有哪些要點？

像固定頁面、地區頁面這類有意義的 URL 維持不變(keep)，只把系統自動編號、沒有意義的 URL，301 轉址到具有有意義 slug 的新 URL。設計規則上會嚴格遵守兩點：轉址一律以1個跳轉完成，不建立轉址鏈；並在建置時加入驗證機制，確認目的地 URL 確實存在，避免把301導向不存在的URL這種事故。上線後會在 Search Console 監控數週，直到轉址被正確辨識為止。

改版時為何會發生問詢反而變少的問題？

因為在重新設計外觀的過程中，價格、營業時間、聯絡方式、優勢等直接影響問詢決策的資訊，有時會在不知不覺間被遺漏。對策是針對每個主要頁面，先列出舊網站必須保留的資訊(價格方案、受理時間、可提供的服務等)，做成內容保留檢查清單，上線前逐一比對新舊頁面。重點在於不憑感覺或記憶，而是用清單來確保資訊不遺漏。

沒在用的其他網域上的登陸頁，放著不管沒關係嗎？

放著不管是有風險的。這個案例中，冷藏冷凍配送用的舊登陸頁網域疑似因 DNS 失效而無法解析，即使內容已經移植到新網站，也無法從舊網域設定301轉址。若不維護、不續約網域，就有可能在某一天，突然失去該網域長年累積下來的反向連結評價與品牌詞搜尋流量。考慮改版時，應同時確認舊網域的合約狀態與 DNS 是否仍存活，在還能復原的階段就設定好301。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。