有个单位改造到一半才发现关键组件没有替代方案，前期调研真不能省。

交付和验收

把要做的事列成清单，一条一条对着做，比凭感觉推进靠谱得多。

遇到拿不准的，先做两个版本试试，数据会告诉你答案。

说实话，先做小的试点，跑通了再铺开，风险可控得多。

第一步一定是把现状摸清楚。不知道现在什么样，谈改进就是空谈。

我记得，执行过程记一笔，复盘和交接都用得上。

关于页面数量，我的建议是先做精几个核心页，比铺一堆空页面强。真遇到就明白了。

收录是第一步。页面都没被收录，谈什么排名。去后台看看，有多少页面是没进索引的。

需求中途加功能是常事，但一定要走变更流程，不然项目和预算都会失控。

做网站第一步不是设计，是想清楚目的。是为了获客，还是为了给客户看资质，这两个做法完全不同。

我自己踩过，客户说要「高端」，我会让他找几个喜欢的站给我看，比我猜强。

文章之间互相链接，既方便用户也方便抓取，这活儿花不了多少时间。

我发现问答类的内容特别容易被引用，因为结构清楚，一句问一句答。

服务器别图便宜。三天两头打不开的站，做得再漂亮也没人看得见。各家情况不一样。

别只看价格。便宜做出来的东西，后面返工花的钱更多。别等出问题才想起来。

说白了，时间上要现实一点，定制站动辄说几天交付，质量很难保证。

联系方式要显眼，最好每页都能看到。用户想找你的时候找不到就白搭了。我反正是这么看的。

结构化数据听起来挺技术，其实就是给内容加标签，让机器更容易看懂你在说什么。

先说个前提，一页一词，别贪。贪的结果往往是哪个都做不好。

预算和周期要一起谈。只压预算不谈周期，最后质量一定打折。

你先记住这个。

基础的安全配置别省，这个属于及格线。

案例别只放合作方名字，把过程和结果写出来，说服力完全不同。

多语言站点别靠机翻，老外一眼能看出不地道，信任感直接掉。

后台一定要好用到客户自己能改内容。我见过那种改一个字都要找技术的后台。

我习惯给每个页面设一个目标，比如留资、加微信、打电话。没有目标的页面，做起来容易散。

想被引用，内容得有明确的结论，模棱两可的那种很难被选中。

功能贵在实用，堆一堆用不上的，只会拖慢网站。

换个说法，历史内容的去留提前理一遍，迁移时不会手忙脚乱。

介绍页面写点实在的，比如团队构成和做事方式，比喊口号强。真遇到就明白了。

售后响应时间要写进合同。出问题几天没人理，谁都受不了。具体还得看情况。

权限要分清楚。谁能发、谁能改、谁能删，提前定好。

了解一下实际执行的人，转包太多会影响沟通质量。

前期需求说得越具体，后期返工越少，这条基本不会错。

需求聊的时候我一般会问：现在业务上最头疼的是哪件事？从这儿入手最实在。

别把力气全砸在首页。大部分流量实际上是从内页进来的。

内容和细节别糊弄

用脚本动态生成内容的页面，抓取方不一定看得见，这点要测试。我觉得值这个功夫。

错误提示要说人话。「提交失败」这种提示等于没说，得告诉人家哪错了。

搜索友好的结构最好一开始就规划好，事后补代价很大。

这事吧，系统日志保留一段时间，出事的时候能查到线索。

速度这事容易被忽略，但直接影响用户去留。

后来才发现，移动端现在才是主战场。我评审网站都是先看手机，再看电脑。

听起来简单，视频和图片的搜索量涨得挺快，有资源可以顺手布局。

域名和服务器账号这种东西，务必自己拿着。麻烦都是出在这种细节上。

签合同前把交付内容列清楚，尤其是源码和维护这两项。

移动端单独验收，两边差别经常超出预期。

有个细节，先列旧站的毛病，再谈新站要什么，这个顺序比较靠谱。

希望这些啰嗦的话有点用，哪怕省你一次返工。