所謂死鏈，一句話就是 “打不開的鏈接”，一般狀況下所發生的死鏈是由於網頁被刪去、網站改版 (本來舊 URL 由於站點改版 URL 發生了新的改變，網站改版後正確的 URL 是改版後的鏈接，當多用户輸入本來的 URL 地址時就是過錯的鏈接因而該頁面不存在) 、資料庫過錯或許是站羣程序自動生成等原因。
而關於查詢引擎和多用户來説，死鏈接都是不行友好的，假如一個網站存在許多死鏈接的話，如不及時處理，將會被查詢引擎賞罰降權，情節嚴峻的話該站點還有可能會直接被 K 掉。
已然死鏈接的存在對網站的優化極為晦氣，因而從網站中清理出死鏈接並進行優化就是查詢引擎優化 er 的必備作業，關於哪些由於<0>、頁面被刪去而形成的死鏈接，由於這些頁面還可能會被多用户從查詢引擎中查詢到，然後發生拜訪，為了提升站點多用户體會，所以處理死鏈的辦法能夠選用 404 頁面進行提示多用户。
所謂 404 頁面就是當多用户輸入了過錯的鏈接時而回來的頁面，它的意圖就是通知多用户所請求的頁面不存在或鏈接過錯，一起引導多用户運用網站其他頁面進行拜訪，而不是直接封閉視窗脱離。如下圖所示：(在默許狀況下，windows 體系中 IIS 常見的 404 頁面)
關於像這樣的 404 頁面並不具有促運多用户留在站點的作用，所以需求將這個頁面進行有用的自定義。 (在這麼多年以來，還經常看見一些站點沒有自定義 404 頁面，翻開的死鏈接所回來的頁面就如上圖所示，像這樣的站點底子沒有優化認識) 。
自定義 404 過錯頁面是增強多用户體會的很好做法，可是，在應用程序中許多新手查詢引擎優化 er 往往沒有注意到它對查詢引擎的影響程度，比方：過錯的站羣服務器端裝備導致回來狀況碼 “200” 或自定義 404 過錯頁面運用 MetaRefresh 導致回來 302 狀況碼。
正確設定的自定義 404 過錯頁面，不只應當能夠正確地顯現，一起，應該回來 “404” 狀況碼，而不是回來 “200” 或 302 狀況碼。儘管對拜訪的多用户而言，HTTP 狀況碼究竟是 “404” 仍是 “200” 並沒有什麼區別，可是對查詢引擎來説則是適當重要的。
查詢引擎蜘蛛在請求某個 URL 時得到 “404” 狀況碼回應時，就知道該 URL 現已失效，便不再索引該網頁，並向資料中心反饋將該 URL 表明的頁面從索引資料庫中刪去，當然了，這個刪去程序有可能需求很長時間。假如想快速完全的刪去死鏈接，主張咱們使用 “百度查詢資源渠道” 網站支撐中的死鏈提交東西。
’
咱們能夠從以上圖中死鏈提交注意事項瞭解到，經過 “百度查詢資源渠道” 進行死鏈提交 3 天將收效，詳細怎麼進行死鏈提交，“百度查詢資源渠道” 將有比較詳細的闡明，咱們在操作程序中，有不明白的能夠先了解清楚，於此，就不過多闡明晰。
而當查詢引擎得到 “200” 狀況碼時，則會以為該 URL 是有用的，便會把該頁面進行索引建庫，這樣的成果便是這兩個不同的 URL 具有完全相同的內容，自定義 404 過錯頁面的內容，這會導致呈現仿製網頁問題，輕則可能會查詢引擎降權處理，嚴峻則會以為網站存在做弊行為而遭受到嚴峻賞罰。
要讓 404 頁面既不會誤導查詢引擎蜘蛛，又能起到留住多用户的意圖，最簡略的辦法就是修正站羣服務器默許的 404 頁面，使之符合優化需求。別的，現在網絡中有許多人供給了十分精巧和有創意的 404 頁面，有愛好的朋友都能夠結合自身的需求選用。
以上談了兩種狀況引起的死鏈接並共享了怎麼刪去死鏈接，現在談另一種發生死鏈接的要素，由疏忽或許站羣程序過錯形成的死鏈接以及優化。由於站羣程序過錯或許站羣網站優化負責人的疏忽，很簡單形成死鏈接，並且這些鏈接由於是批量生成的，往往數量許多，並且不簡單被發現。
列如，假如查詢引擎優化人員過錯地設定了一個關鍵詞鏈接規矩，加入了一個自身並不能翻開的指向網址，這就是會形成一切 WordPress 網站內容頁中觸及這個詞時發生 1 個死鏈接。
假如這個關鍵詞是這個網站的首要搶手詞，呈現的頻率很高，並且網站的內容頁足夠多，成果就是一次更新頁面以後將會發生無數個死鏈接。除了站長們疏忽以外，有些 CMS 體系再資料庫處理刪去、搬運內容頁操作時，也很簡單發生死鏈接，在這樣狀況下發生的死鏈接修正起來比較費力，並且十分不易被發現。