不管開發Web 網站所使用的是何種內容管理系統或Web 應用程式框架，都應該涵蓋一些基本要素。能提供精緻的使用者介面和豐富的內容固然很棒，但在那之前，首選應該提供用戶能查找到並能明了地表達該網站用途的基本文件。 引言 有幾個標準的檔案是每個Web 網站都必需的，但在很多時候它們會被網站忽略。大多數這種文件都與約定有關，而非技術上的要求，但如果不能提供這些文件，就會使網站建立誤入歧途。除了URL可以透過猜想嘗試得到，通常用戶很難透過猜測找到其他想要的東西。本文將對這些標準文件逐一簡述。 給定的資源究竟如何提供決定於所使用的Web 伺服器層和Web 應用程式層。在諸如Apache 這類「傳統」 的、接近靜態的伺服器內，這些資源很可能就是伺服器上的文字檔案。但在不同的配置中，它們也有可能是資料庫中的某些條目、設定檔中的某些行、伺服器進程中的某些類別等。本文重點放在使用者最終所見之上，而非該如何讓其發生。 404.html 當使用者使用您的Web 站點，他們不可避免地都會尋找一些不存在的資源。比起其他原因，這類尋找更多是由於URL 的拼字錯誤而致，但連結過時、後端的錯誤配置、不同點的URL 殘缺等因素也不容小覷。當資源不可用時，一個很好的做法是提供某種迴轉頁面以協助使用者導航到其他有用的頁面。一個普通的「沒有找到」 雖然可以讓使用者知道資源不可用，但卻無法幫助他們解決「下一步如何做」 的問題。 警告：在創建自訂的404.html(或Web 伺服器用來發布自訂「沒有找到」 訊息的任何其他機制)時，太多的Web 網站都會被錯誤地配置成發送「soft 404」 訊息。換句話說，它們會發送一個帶有常規的“200 OK” 標題的頁面，這僅僅說明了文本的某個地方“不可用”，也許還提到(但不經常)此處有“404 Error”。應該避免這樣做。相反，應該讓使用者(和他們的Web 瀏覽器以及其他工具)省些事，使用確切的狀態標題。 about.html 那麼，究竟為何要創建Web 站點呢?沒錯，需要用一個首頁來回答這個問題。但更可能的情況是，首頁並不提供這類信息，而只是讓用戶能夠登入、突出網站的「賣點」、顯示某些花哨的內容等等。也許還需要讓使用者能夠從首頁導航到「關於」 頁面，如果真是這樣，請務必讓資訊能夠從http://mysite.example.com/about.html 取得。有些人習慣從此頁尋找這類資訊。 一個好的about.html 頁面應該能夠提供有關網站功能、建立此網站的意圖以及使用者為何要關注此網站的總覽，而且還有可能會有幾個連結能夠幫使用者導航回網站的核心功能。此頁無需、而且通常也不應該十分華麗。只需讓它保持務實且準確，以便用戶能夠利用網站所能提供的所有功能。 contact.html 那麼，如何聯絡您?借助about.html，用戶可以透過在現有主頁上的多次點擊來獲得此資訊。 copyright.html 網站的版權歸誰所有?有可能內容屬於您，但您又是誰呢?個人?公司?合夥人?政府機構?如果內容屬於公共領域或在自由內容許可的範疇內，那麼可能需要告知用戶這一點。時下，幾乎任何內容都有各自的版權歸屬：如果您的內容遵從不同的原則，那麼就請告知使用者。但目前費心提供這類資訊的網站還不夠多，但為何不將它添加到自己的網站呢?因為總會有些用戶會關注這方面的資訊。 很明顯，不同的頁面或資源可能有不同的版權資訊。請利用這個頁面為使用者提供有關如何確定那些個別差異的資訊。如有商標方面的問題，請一併提供。 index.html(和index.htm) 並不是每個Web 伺服器都實際使用index.html 檔案來描述其主頁。根據設定的不同，可能會有URL 重寫、依路徑名動態產生等手段。但使用者並不關心這些細節!只需讓http://www.aaa.com/index.html 指向主頁，即便是為了實現這一目的而必須要使用簡單HTML 重定向。 對了，既然如此，那麼就索性讓老的.htm 擴展名也生效吧。如果還覺得不夠，就對index.cgi 也如法炮製吧。 index.rss 很多Web 內容都可透過RSS 提供。雖然此種做法並不適用於所有Web 站點，但對大多數站點而言還是比較有效的。讓RSS 內容獨立於特定於使用者的配置選項、登入或為特定的資訊付費的做法極為合理。因為RSS 也不能面面俱到。 雖然如此，如果有些東西可以作為RSS 提供，那麼請儘管這樣做。也許，在index.rss 給出的不過是「廣告」 內容，有時還會一併提供如何利用RSS 提要的種種優勢的老生常談。有時又或許是有關RSS 為何與您的Web 網站不相關的一個說明。 privacy.html 一旦想要收集使用者資訊(即使只有使用者名稱或流量日誌)，就要告知使用者您打算如何處理這些資訊。圍繞Web 網站創建者和/或使用者的權力和責任的法律問題十分複雜。不過，若能考慮到用戶的個人私隱，用戶還是會感覺到的。而且也許您就應該在此時與律師商談一下該如何處理使用者的資料。 robots.txt 如果不想讓Web 網站上的所有資源都能被自動工具編入索引，就請在robots.txt 檔案內加以說明。但如果確實想讓內容都編入索引，也請如實說明。 Robots Exclusion Standard 指令並未強制使用者：如果的確不想讓某些東西可見，就請不要將其放到站點，或確保其後有足夠的許可保護。不過，所有主要的合法Web 爬蟲引擎都會遵從robots.txt 內的要求。因此請盡量明確說明您的意圖。 security.html security.html 的使用並不強制。但如果網站存在安全性問題(例如，從使用者那裡收集了任何敏感的資訊)，為安全性流程建立文件說明(至少給出大致的概括)不失是個很好的做法。請在此頁給予聯絡資訊以防使用者有任何疑問或想要給予如何改進的建議。尋找這些資訊應該遵從網站導航選項的整體組織。既然如此，不妨在這個URL 也放上該資源。 網站地圖 如何顯示整個Web 網站的地圖尚未完全標準化。為製作網站地圖而提供的某些東西總是很有用的，但這些東西究竟詳細到何種程度取決於網站的動態程度(或動態的方式)。而且，想要為使用者顯示的內容也依賴網站的意圖。例如，如果使用者沒有對資源X 的使用權限，那麼讓使用者知道資源X 的存在可能根本不合適。請根據自己的判斷和具體情況，設法提供一些東西。 對於許多站點，提供站點地圖只不過是對諸如搜尋引擎這類自動機制的支援和友善。 Google 在robots.txt 約定的基礎上發布了一個新的約定。總之，可以建立一個XML 檔案來給出網站所提供的所有資源。這有點像一個“包含列表”，充當了robots.txt 的“排除列表” 的補集。 電子郵件地址 只考慮Web 上的東西還不夠。有時Web 網站的導航工具並不能盡入人意(或有的使用者可能會對您的優雅設計不理解)，因此最好讓使用者也能透過電子郵件聯絡到您。 請務必在Web 網站的contact.html 或其他地方顯著地公佈聯絡資訊。但也請確保發到一般性的電子郵件地址的郵件能夠送達給合適的人員。這至少包括[email protected]、 [email protected] 和[email protected]。對於那些“老輩人”，可能需要讓發給[email protected] 的郵件也能轉達到合適之處(但出於安全性原因，可能不是到“root”)。請加入少許對電子郵件轉發進行說明的文字，這些文字應該能清楚表明網站目的。電子郵件地址就像Web 伺服器目錄中的符號連結一樣易於使用。