當我們初步對搜尋引擎的運作模式有了概念之後，就進入到真正 SEO 實際操作的環節了。很多 SEO 網站都會把最佳化實踐放在SEO 技術，而並沒有花太多時間關注到網站本身的架構。
而從我個人的理念來說，我們應該要先搞懂架構，所以這一期，讓我們來說網站架構吧。
做為數字化行銷甚至數字化轉型的過程中，SEO 最佳化非常重要，我相信有很多公司的網站都已經存在很長一段時間了，就趁著這個時刻，把公司的網站架構好好整理一下，一方面有擺脫2020年新冠疫情，呈現萬象更新的氣息；另一方面也可以在調整後，帶來更多的潛在用戶完成轉化，讓公司的業績更上一層樓；甚至還可以強化品牌的認知度，讓更多人認識你的公司，提升品牌知名度。
這裡有一個小問題請問各位好友：當你要研究搜尋引擎 SEO 的時候，你會如何切入研究呢？我覺得很多人都會認為 SEO 其實很難，確實很難，但如果讓你提一個朋友，你要怎麼描述這個朋友呢？也很難，對嗎？其實搜尋引擎可以想像它就是一個擬人化的「朋友」，知識淵博，天南地北無所不知，只是它不是實體，而是一個工具、一個系統、一個平台，就決定你如何看待。更何況當 Google 這樣的搜尋引擎引進機器學習，成為一個有智能學習能力的人工智慧系統時，就更相近我們所描述的「朋友」概念了。
對搜尋引擎來說，網站就如同一個地圖，提供給它就是讓它也搞清楚這個地圖裡面有哪些東西是需要這個搜尋引擎搞懂的。因此無論是新建網站或是將舊的網站要重新改建的時候，都需要確認以下幾件事：
- 這個網站是新的網站，還是將舊的網站翻新設計呢？
- 這個網站是多國語言版本，還是本國語言版本就好？
- 相關的客服、技術支持、計費、售前服務，是需要兩套還是一套？
- 網站的架構是否已經 SEO ready？
如果你即將接手的是一個新網站，那要恭喜你，因為你避開了一個大坑。如果不是，那你要考慮的問題就多了。對公司等級的網站來說，要考慮的範圍不單是網站的分類、網頁內容，還有更多的是我在上面提出來的問題；更複雜的倒不是事情的多與雜，而是內部溝通協作的成本會相對提高。曾經拿過諾貝爾經濟學獎的隆納·寇斯它的論文當中就提過企業內的交易成本一旦過高，企業存在的意義就不大了。而企業內部的協作，往往會因為組織規模的擴大而逐漸增加交易成本。
還記得我在前一個工作報到的第一天，被大老闆找去「聊聊」，第一天收到的「任務」就是「把公司的網站搞好」。在那之前，我公司的網站雖然已經維護了七八年了，但當時初步的了解就是設計人員把公司的網頁重新做一遍，連舊的網頁都沒有刪除或是301重定向。公司網站上的產品頁面一共有4個版本，最早是2008年的，後來有2012年版、2015年版、以及最後的2017年版，雖然展示在眾人面前，知道現在的版本是哪一個，但搜尋引擎怎麼會知道呢？於是我就被派任這個艱苦的「任務」了。我花了整整四個月，才把這整個網站全部更新完成。
符合SEO規範的網站架構的特徵
一個符合SEO規範的網站有什麼規矩需要滿足的呢？我想有下列幾點：
- 清晰的網站架構藍圖
- 代管的網站讀取的速度要夠快
- 域名網址簡短而且容易記住
- 完善的導航連結
- 網站本身具備了資料化結構
- 網站內容有經過最佳化（優化）的管理紀錄
接下來就一步步說明每一項規則，讓你可以快速上手：
清晰的網站架構藍圖
網站架構圖的重點在於讓你可以將整個網站的內容依照不同的方向與目的進行區分，完成分類與階層化，
架構層級不要太多：維持在 3層是比較合適的。即便如 Amazon 這麼大型的網站，也頂多就是 4 層。架構多，對搜尋引擎來說，會認為越底層的頁面代表越不重要。
橫向的分類也不要太多，維持在 7-8層就好。前面提到，縱向的網站架構不要太深，最好控制在 4 層之內；同樣的，當你的網站橫向分類過多，也不利於搜尋引擎探索，最好維持在 7-8層。
代管的網站讀取速度要夠快
你的網站是自己架設伺服器提供服務，還是放在數據中心呢？除了一般說的網站連接速度之外，你的主機效能、頻寬、網頁程式碼、前端頁面以及後端內容管理系統是否都有良好而完善的設計？網頁程式碼是否符合 HTML 4 以及自適應條件，能滿足PC以及智慧型手機的網站瀏覽體驗？如果你想快速檢測網站的速度以及網頁的易用性，不妨利用 Google Search Console 這個免費的網站應用，可以讓你快速檢查網站兼容性以及網頁速度檢查。
符合 SEO 需要的統一資源定位符（URL）
首先我想你們應該都知道 URL （統一資源定位符）是什麼意思。URL就是在Internet上位置的頁面地址。 每個頁面的連結都會顯示在瀏覽器的地址欄中。
標準URL結構包含：
- 在前方會有鎖頭，代表網頁是加密的；如果沒有加密，鎖頭是打開的。Google 是不允許未加密的網站顯示在SERP 當中的。當然，如果你選擇使用的是大陸的網站，是很有可能遇到未加密的網站的。
- 數據傳輸協議，例如https：//。通常不會顯示 https://，而是瀏覽器會隱藏起來。但這個是有例外的，尤其是當站長將 www 也設定為子域的情況下。這個部分我會在之後再做介紹。
- 域名：分為主域跟子域。關於主域以及子域的介紹，我會在之後的說明當中解釋細節。
- 域名到頁面的路徑，包括目錄和子目錄鏈。
- 可能包含特殊參數和錨點，例如用於獲取資源內容的GET方法。
域名是URL的一部分。 站點名稱後面的其他組件的長度可能會有所不同，並具有不同的內容。 最終結果取決於目錄的名稱以及該目錄所指向的頁面的名稱。URL語法允許使用字母，數字和其他字符。
連結的長度主要對於用戶而言很重要。 通常，長網址超出了地址欄的可見部分，並且具有複雜的結構。 將此類連結複製並放置在第三方資源或文本文檔中時，其文本可能需要多行。
具有2-3個易於理解且引人入勝的單詞的短鏈接看起來比長鏈接更有吸引力，它們的可點擊性可能會更高。 如果你需要在地址欄中手動輸入長網址，會花費很多時間。
域名網址簡短而且容易記住
公司級別的網站，對新人來說，從某個角度上看，是公司領導層對你的認可，但從另一個角度看，這可並不是一個輕鬆的活。我在前公司針對公司現有網站操作最佳化的時候，發現現有的網頁有不同的文件夾，而且導航混亂，網址也跟隨者不同時代的站長隨自己喜好自定義名稱。由於公司需要協調的單位很多，每個人又誰都不服誰，溝通效率非常差，最後只好動用公司CEO親自召集，統一各個部門的意見，協調出來整個網站的框架以及名稱，才算是初步完成公司的域名結構。
如果你遇到的網域只有本地的語言，而且網站規模不大，我建議你可以採用子目錄的形式簡化網站架構；如果是多國語言，那麼可以跟各地分公司協調好，是採取當地域名註冊，還是採用子網域，或子目錄的形式，統一整個網頁架構，這樣才不會出現混亂的網頁結構編制。子域、子目錄、本地註冊不同的選擇對網站設計所產生的權重都會有一定的影響，因此要審慎考慮。
- 子網域：abc.xyz.com
- 當地域名註冊：www.xyz.co.jp (以日本為例）
- 子目錄：www.xyz.com/product/abc
在設計公司於明網址的時候，建議要將同一個域名之下之前已經發佈過的老頁面用301重定向的方式規整到新的結構當中；此外也要注意不同語系的用字，是否使用 UTF-8 格式確保內容不會出現亂碼；還有對CSS的管理也需要注意是否不同語系之間使用的CSS也會有所不同。這些都是需要考量的。
完善的導航連結
網站本身的架構如果原本就有結構性，那麼整個網站的導航連結也會比較有規範。不過還是有幾個小地方需要請大家留意：
- 網頁的層級要精簡：對搜尋引擎來說，你的網站層級越多，對搜尋引擎而言就代表重要性更低。以 Amazon 來說，上億的商品在這麼大的一個網站下，但它的層級最多也不過就是4級。下圖就是一個電子商務網站的示意圖
另外以下的規則也應該要遵循，因為這些內容都可以說是會被搜尋引擎納入考慮的範疇。
- 不同層級的網址導航建議選擇有意義的關鍵字：每一個層級使用的文件夾或是網頁名稱其實都應該與關鍵字相關，當關鍵字與網頁內容結合起來，對搜尋引擎來說，才會覺得這個網站以及網頁的緊密度可以帶給用戶更有價值的認知。
- 網址不要有錯字：網頁裡面如果有錯字，一方面會造成誤判，搜索引擎並不知道你輸入的內容是正確的，還是錯誤的。我曾經參與的專案當中，有一個網站的站長在網站架構當中使用了錯誤的關鍵字 artifitial，但事實上應該是 artificial，所以它的頁面雖然內容正確，但因為架構上的錯誤，導致網頁本身瀏覽量不高，SERP 值也低落。
- 網址不要太長：網址並不是越長越好，在進行網站最佳化的時候，最好選擇簡潔明了的連結，而不要使用結構複雜的長URL。頁面地址應該簡短，邏輯，用戶可讀並包含關鍵字。這樣的連結會影響吸引力。一方面搜索引擎對網址的長度有限制，以微軟的 Internet Explorer 來說，網址最長不能超過 2048 個字符。但是，瀏覽器成功處理超長連結並不意味著搜索也能夠對其進行處理。相應的頁面URL長度只有75個字符。如果你的 URL 很長，對於使用長URL（超過75個字符）的文檔編制索引，儘管排名可能會遇到困難，但通常它們的索引編制得很好，建議你使用友好連結，減少嵌套級別，使用連結最佳化的結果對用戶會有很大的助益。
- 網址建議減少使用動態網址，但如果有，請準備完整的參數：這點可能是爭議最多的環節之一，因為在大部分的SEO 網站上，我看到許多SEO優化師都會建議許多人儘量轉為靜態網頁，但我在 Google 的說明中卻看到了不全然相同的結局。簡單來說，由於信息量在這幾年快速增加，很多頁面都需要硬編碼，所以對那些大型網站的網站站長或是管理員，他們對於那些經常會變動內容的網頁（如：電子商務商店，論壇社區，博客或內容管理系統）通常會使用動態 URL，而不是靜態 URL。時可能會使用動態URL的原因。如果站點的內容存儲在數據庫中並按需拉出以顯示在頁面上，則可以使用動態URL。此時這個站點會提供一個範本頁面（template page），當用戶調用選擇了資料庫內儲存的內容時，網站系統就可以透過查找資料庫組頁的方式呈現結果頁面。你可以透過查找以下字符來發現動態URL： =＆。動態URL的缺點是不同的URL可以具有相同的內容。因此，不同的用戶可能會鏈接到具有相同內容的具有不同參數的URL，這就是網站管理員有時想要將其URL重寫為靜態URL的原因之一。對 Google 來說，他們給的建議是：提供原始動態URL，這樣透過 Google 的系統處理檢測和避免有問題的參數的問題要安全得多。如果堅持要重寫URL，保留外觀動態的，要記得刪除不必要的參數。
- 降低原先 Ajax 網頁的使用量，改成新的網頁展現：如今會使用 Ajax 的網頁基本上都屬於老網站了。如果你遇到 Ajax 網頁，請直接列入最佳化的範圍，改成新的網頁處理，杜絕後患。
網站本身具備資料化結構
當你的網站提供了大量的產品資料或是比較資料，想要呈現不同的複合式搜尋結果，你可以在編輯頁面的時候選擇透過 schema.org 所提供的標準樣式加入「結構化資料（Structured Data）」。結構化資料是一種為網頁歸類的標準化格式，能幫助搜尋引擎更容易地了解網頁的資訊。你可以用 Google 結構化資料測試工具或 Google 複合式搜尋結果測試等工具檢測網頁資訊是否標記正確。不過並不代表你使用了結構化資料，Google 一定會展現這些資料，因為 Google 會判斷及呈現最佳的搜尋結果。最好的做法是提供更完整的引言吸引用戶查詢複合式搜尋結果。當你適當地採用結構化資料後，搜尋引擎能對你的網頁內容有更深入的了解。當網頁搜尋結果有多元化的方式展現，不但可吸引更多的點擊和流量，甚至促進更多的互動和分享，能間接地影響和提升網頁的排名。
網站內容有經過最佳化的管理紀錄
當你拿到一個網站準備更新的時候，建議你最好使用工具檢查這個網站內容是否已經做過網站最佳化管理。網站最佳化管理工具不僅可以告訴你網頁標題尺寸是否適當、圖檔是否添加了 ALT，甚至網頁本身是否有 meta description 元描述內容，都可以很快地查詢結果。市面上提供網站最佳化工具非常多，我習慣使用 semrush 做為我的管理工具，後面我會陸續介紹這些工具。
終於寫完了這一篇文章，看起來很簡單的內容，但卻花了我好多時間才補齊（重點是我還是覺得不滿意，也許日後會再修改）。有時候簡單的內容卻是最難完成的。這點我實在要好好檢討。
