一个需要优化的网站，我们可以从以下四个方面进行优化分析：网站基础优化、网站内容优化、网站结构优化、外部链接优化。
　　一、网站基础优化
　　基础性优化即网站内容适合搜索引擎收录的一系列前期工作，现在已渐渐融入到网站开发的环节里，成为必须的工作内容，每个基础优化的细节对网站的影响都很小，但所有因素融合到一起就可以产生一定效果了。这些因素包括：
　　1、域名
　　(1)搜索引擎对域名的信任度依次为：gov、org、com、net、cn。
　　(2)域名的年龄对排名也有影响，一般来讲，域名年龄越大搜索引擎给予的权重越高。
　　(3)域名包含关键字会好一点点，比如你是卖壳牌润滑油的网站

 　2、title、meta、静态页、url命名、目录层级、html语义布局(div+css)
　　(1) title不要贪多，突出重点;
　　(2)meta的keywords已经不重要了，description的作用体现在百度的收录描述，吸引人的描述，点击的人就会多;
　　(3) 静态页的确更有利于收录，但不绝对;
　　(4) url的命名很重要，百度更喜欢拼音组合，google更喜欢英文组合，首字母的组合方式意义不大;
　　(5) 程序路径层级不要超过3级，

　　(6) html语义布局，即通过div+css实现结构和表现分离，用html的语义表现内容，比如h1代表一级标题，strong和em代表强调。
　　3、关键词密度
　　关键词密度没有严格的标准，合理即可。如果需要设置，建议密度：3-8%，4-5%也许更好，可以用关键词密度工具检查。
　　4、基础建站知识
　　服务器地址、域名解析、代理访问、独立IP、框架结构、iframe调入等，了解这些知识对网站的优化和运营会有所帮助，需要不断学习。
　　5、分析工具
　　关键词挖掘、搜索指数、关键词密度、网页相似度、关键词热度、浏览来源、Alexa排名、PR值、反链调查、网站收录数调查。
　　6、SEO的一些忌讳：隐藏文字、重点内容采用图片或flash或javascript、网页标题频繁更改、垃圾链接太多、关键词堆砌、过度采集、关键词选择失误、网站代码不简洁、网站主题与内容不符、和作弊网站在同一服务器上。
　　二、网站内容优化
　　这里的内容优化不是指内容创作，而是内容的技术性优化，网站编辑需要掌握。
　　1、关键字策略
　　(1) 通过对关键字热度和大众搜索习惯的研究，结合网站内容制定合理的关键字;
　　(2) 合理使用关键字，转载的文章尽量做到半原创。
　　2、内链
　　(1) 多用内链，注意锚链接文字和锚文本;
　　(2) 对重点页面分流PR值。
　　3、了解html基本语义，恰当使用strong和hx等html标签
　　三、网站结构优化
　　结构优化在网站设计的时候就需要注意了，和内容优化一样，需要不断积累经验，结构优化对于网站整体表现很重要。
　　1，网站结构的逻辑清晰，层级简单明了，最好控制在3级以内;
　　2，链接结构清晰明了，适合浏览者阅读及搜索引擎爬录;
　　3，编程语言优化，比如代码无重复、无多余部分;
　　4，前后台实现形式简单明了。
　　四、外部链接优化
　　外部链接优化目前来说是最重要的环节，如果SEO的前三个部分是一种基础性的、框架性的操作，那么外部链接优化就是一个策略性的工作，两个内容相差不大的网站，外部链接优化对排名能起到决定性的作用。友情提醒：一个网站如果想要长远的良性发展，必须做好自身内容。
　　影响外部链接优化的几个方面：
　　1、数目越多越好，平稳增加即可;
　　2、质量越高越好，垃圾的不要;
　　3、链接域名的权重依次为：gov、org、com、net、cn;
　　4、链接网站内容越高越好，私服、违规违法内容的不要;
　　5、链接锚文字尽量用关键词，也要有一部分直接是网址链接;
　　6、链接文字的多样性(不同关键词);
　　7、链接存在时间的长短;
　　8、链接本身及链接文字随时间的变化;
　　9、交叉链接和交换链接的比例，交换链接不易过多。
　　10、链接越多，效果越弱。

表示层：负责直接跟用户进行交互，一般也就是指我们的前台，用于数据录入，数据显示等。它不应该做太多的工作。表示嘛，也就意味着只做与外观显示相关的工作。不属于他的工作他不用管也不该管。
业务逻辑层：用于做一些有效性验证的工作。以更好的保证程序运行的健壮性。如数据的有效性判断。不允许为的地方是否输入了空字符串，该输入Email的，格式是否正确等，数据类型的合法性判断，该是整型的地方当然不能接受字符串了，数据库操作是否合法，如字段长度的有效性判断。sql防注入的问题，用户的权限的合法性判断等，通过以上的诸多判断以决定是否将操作继续向后传递。尽量保证程序的正常运行
数据访问层：顾名思义，就是用于专门跟数据库进行交互。对数据的添加，删除，修改，显示等。需要强调的是所有的数据对象只在这一层被引用，如System.Data。SqlClient等，除数据层之外的任何地方都不应该出现这样的应用。
ASP.NET可以使用.NET平台快速方便的部署三层架构。ASP.NET革命性的变化是在网页中也使用基于事件的处理，可以指定处理的后台代码文件，可以使用C#,VB,J#作为后台代码的语言。.NET中可以方便的实现组件的装配，后台代码通过命名控件可以方便的使用自己定义的组件。显示层放在ASPX页面中，数据库操作和逻辑层用组件来实现，这样就很方便的实现了三层架构。
。
b)          为什么使用三层
那么我们为什么要使用分层开发呢，它有什么独特的优势呢？

      .NET开发平台为我们做开发提供了强大的技术支持，使我们的开发变得非常便捷，高效。通过code behind的强大支持，我们可以将页面设计和代码设计有效的分离，代码编写，页面设计同时进行。这比古老的asp那种插入式编写要迅速多了，Html归aspx，代码归aspx.cs，看起来倒也蛮清晰的，也没发现有什么不妥的地方
的确，光从功能实现的基础来说我们已经做得很好了，尤其对于一个简单的应用来说，代码量不是很多的情况下，这种一层结构开发完全够用了，没有必要搞得那么复杂。但是对一个复杂的大型系统来说这样的设计的缺陷就很严重了(下面会具体介绍，分层开发其实也是为大型系统服务的),。在开发过程中我们会不停把代码到处复制，以实现一些相似的功能。同样的代码为什么要写那么多次？不但使程序变得冗长，更不利于维护，一个小小的修改或许会波及很多页面。稍微不留神就会导致异常的产生。使程序不能正常运行。最主要的面向对象的思想没有得到丝毫的体现，打着面向对象的幌子却依然走着面向过程的老路。

      意识到这样的问题，我开始将程序中一些公用的处理程序写成公共方法封装在类中，供其它程序调用。象一些功能型的代码集合，数据库操作，如同SqlHelper那样对数据操作进行合理封装，把sql语句，参数列表作为参数，在数据库操作过程中，只要传入相应的参数就可以完成特定的数据操作，这就是我一开始的数据访问层，再不用每次操作数据库时都写那些重复性的数据库操作代码。在新的应用开发中，数据访问层可以直接拿来用。面向对象的三大特性之一的封装性在这里得到了很好的体现。似乎找到了面向对象的感觉，代码量较以前有了很大的减少，而且修改的时候也比较方便。这下应该可以了吧？

       试问一下，如果有一天数据库供应商发生了变化，因为数据量的增加，数据库有access变成了sql server？这下麻烦大了，原来的数据访问层失效了，数据操作对象发生了变化，且页面中涉及数据对象的地方也要进行修改，因为原来可能会使用OleDbDataReader对象将数据传递给显示页面，现在都得换成SqlDataReader对象，sql和access支持的数据类型也不一致，在显示数据时进行的数据转换可能也要进行修改。由sql向access的转换所做的修改会更多。还有一种情况，因为某种需要，我们要把Web形式的项目改造成windows应用，这时牵涉的修改有多大呢？如果在你的aspx.cs中放了很多处理代码，或者还有一部分代码存在于aspx中呢windows应用中可没有aspx阿，是不是整个系统需要重新来做了？这都是设计不合理惹的祸。再者，就是分布式的情况，现在的设计也无法做到。也就意味着，以上的设计充其量只能算小打小闹。
不知道我的解释是否让你体会了到了一些一层开发模式下的缺陷了呢？你是否碰到过这样的情况呢？幸运的是，多层开发架构的出现很有效的解决了这样的问题。通过将程序架构进行合理的分层，将极大的提高程序的通用性。

      三层中，各个层之间的分工是很明确的，面向对象吗，就像一个公司中的部门一样，每个部门的分工是不一样的，是哪个部门的任务就有哪个部门完成，对应的，各个部门的维护工作也有各自完成且不会影响其它的部门，至少影响不是很大，否则就只能说明分层还不合理。各个层之间通过有效的协作来完成系统的高效运行。表示层就是用来做接受/显示数据的工作，它要通过与其它层的协作来完成用户的请求，在这一层不该放太多的代码。逻辑层就是用来做数据有效性判断的，前面已经说过了，数据层就是用来完成底层数据交互的。表示层就不该去实现逻辑层的功能，当然我们会在客户端对用户的输入做一些判断，但服务器端，验证还要做。用户完全可以绕过客户端验证不是吗？现在我们在看上面说的问题，数据库发生了改变，我们只需要修改数据访问层，其它的地方我们都不用去管，这里我倾向于借助自定义数据实体来负责层与层之间的数据交互，我们把数据填充到自定义实体中，使用自定义实体的好处请参考我上面的两篇关于自定义实体的介绍的文章。通过数据访问层来完全封装数据供应商，使数据访问层对其它层完全透明，这样将数据库改变带来的修改完全限定在数据访问层内。我们可以借助一些模式来设计一个通用的数据访问层，这样即使数据库发生改变，我们只要修改一下配置就可以轻松搞定。对于开发平台的改变也变得很容易，不管是windows还是web，变化的只是界面而已，也就是所谓的表示层，它的内核没有变，相当于我们重作一个壳。表示层的代码是很少的，所以修改是很有限的，其它两层也不要修改就可以迅速做到web程序向windows程序的过渡。
你体会到三层的优势了吗？当然多层设计还有很多优秀的地方，我只是介绍了其中的一小部分。下面引入我所理解的三层的概念。
c)          我的三层结构。
那么怎么才能写出一个比较好的三层结构呢？下面说说我在程序设计中采用的做法，当然这里谈的只是我对三层的理解，不一定准确。欢迎拍砖。呵呵
         程序设计追求的是代码的通用性，可移植性，可维护性、功能扩展。怎么才能做到这些呢？这需要我们大量的实践经验做支撑。对面向对象思想的深入了解才能做到。个人觉得优秀的多层结构的设计肯定要先精通模式设计，不过遗憾的是对模式设计研究好长一段时间，依然没能领略到它的精髓，研究模式设计真的很过瘾哦。

Web层：也就是表示层，它负责响应用户的请求，对于这一层越薄越好，一般不应该写太多代码，或者为了页面显示的需要做少量的代码。大量的处理工作都交给其它的层去完成。就好比传递员，只负责接受，并将请求向后传递，具体怎么做它不用管。

Common层：这里用来封装一些常用的功能性代码，主要用来为其它层服务的。还有存放一些自定义实体类型和自定义实体类型集合。用于各层次之间数据交互的载体。如User，UserCollection，关于自定义实体这里就不展开了，如果系统复杂的话这一层应该比较厚实，包括下面的BLL层也是如此。
BLL层：就是逻辑层，用来对数据进行有效性验证，牵涉到对敏感数据的操作都需要经过这里做判断，然后才能决定操作是否合法。

Dal层：数据访问层；封装对数据库的操作。我们可以做一个通用的数据访问层，下次开发的时候，就可以直接拿过来用。很爽的。有一点从这里传进来、传出去的数据都用自定义实体代替，这样就可以实现数据访问层对其它层的完全透明。这里封装所有于数据库相关的代码，包括sql语句，存储过程等。

分层的思路说完了，在多人开发系统的过程中，就可以按层来划分任务，只要设计的时候把接口定义好，开发人员就可以同时开发。而且不会发生冲突，做前台的人根本就不需要知道数据库结构是什么，该怎么去查找，更新，删除数据，他直观调用响应的方法就可以了。数据访问层的人也不需要知道前台发生了什么，定义好与其它层交互的接口，规定好参数就行。各个层都一样，做好自己的工作就可以了，只要能做到对其它层的完全透明。这样就可以将修改限定在一个比较小的范围内。

但各个层具体的代码该怎么组织，我想这就要看个人的造诣了，要开发出高性能，可扩展的代码就需要结合模式设计的思想，通过代码结构的科学、合理的设计方能在日后的维护过程中游刃有余。

三、      总结

1)        从开发角度和应用角度来看，三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发，每人可以有不同的分工，协同工作使效率倍增。开发双层或单层应用时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用时，则可以结合多方面的人才，只需少数人对系统全面了解，从一定程度工降低了开发的难度

2)        三层架构可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行，充分利用网络的计算功能。分布式计算的潜力巨大，远比升级CPU有效。美国人曾利用分式计算解密，几个月就破解了据称永远都破不了的密码

3)        也是三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了