引言
有幾個標准的文件是每個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 或其他地方顯著地公布聯系信息。但也請確保發到一般性的電子郵件地址的郵件能夠送達給合適的人員。這至少包括 postmaster@aaa.com、 webmaster@aaa.com 和 security@aaa.com。對於那些 “老輩人”，可能需要讓發給 root@aaa.com 的郵件也能轉達到合適之處(但出於安全性原因，可能不是到 “root”)。請加入少許對電子郵件轉發進行說明的文字，這些文字應該能清楚表明站點目的。電子郵件地址就像 Web 服務器目錄中的符號鏈接一樣易得易用。