不管开发 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 或其他地方显著地公布联系信息。但也请确保发到一般性的电子邮件地址的邮件能够送达给合适的人员。这至少包括 postmaster@aaa.com、 webmaster@aaa.com 和 security@aaa.com。对于那些 “老辈人”，可能需要让发给 root@aaa.com 的邮件也能转达到合适之处(但出于安全性原因，可能不是到 “root”)。请加入少许对电子邮件转发进行说明的文字，这些文字应该能清楚表明站点目的。电子邮件地址就像 Web 服务器目录中的符号链接一样易得易用。
