出故障的时候才知道预案有多重要，我遇到过。
售后和维护
响应时效约定清楚，这是售后的核心。
- 联系方式变更要第一时间同步给对方，这个细节经常被忘。
- 应急预案不能只是文档。真出事的时候，得有人知道第一步做什么。
- 故障分级挺有用。小问题几小时解决，大问题几小时响应，分清楚。
- 改动前做影响评估，这是避免连锁反应的办法。
- 系统升级要提前通知，别在业务高峰做。
换个说法，迭代计划建议按季度排。想到什么做什么，最后会堆一堆半拉子工程。
备份不能只是做，要定期演练恢复。
已知风险提前告知，这是负责任的做法。
备份要自动化，靠人记着肯定会有忘的那天。
维护期内发现的小问题，集中整理一次再提，比零散提效率高。
售后响应时间要写进合同。出问题几天没人理，谁都受不了。
维护包含哪些动作，提前界定，不然每次都要谈。
长期不动的系统也会有安全问题，定期检查别省。
- 合同里一定要写清楚交付物：源码给不给、后台有没有、后期维护谁负责。
- 网站不是做完就完了。内容更新、小改小动，这些才是长期的事。
数据备份要有。我遇到过一次硬盘故障，幸好有备份，不然全都得重来。
先说个前提，网站上线只是开始。内容更新、数据查看、小改小动，这些才是长期的活。
- 维护的范围提前写清楚，免得后面每次都要重新谈。
- 补丁要及时打，这是最基础的安全习惯。
内容和细节别糊弄
多语言站注意文字长度差异，布局要有弹性。
搞一堆站发同样内容，听着聪明，实际上容易被一锅端。
- 别在一个页面上塞好几个词。一个页面解决一个问题，聚焦反而容易出结果。具体还得看情况。
- 表单别设计得太长。让用户填四项，他能填完三项就算给你面子了。
- 服务器别图便宜。三天两头打不开的站，做得再漂亮也没人看得见。
老实说，URL 别太长太乱。一串参数的链接，用户看着就没什么信任感。真遇到就明白了。
- 备案要提前规划，临时抱佛脚很容易耽误事。
- 简单说，SEO 关心的是排名，GEO 关心的是引用。一个是位置，一个是内容本身够不够格被拿走。
有个细节，内容结构别照抄同行。你跟他的客户群体、产品结构都不一样，抄过来很多地方是空的。
听起来简单，图片要压缩，原图直接往上放，加载速度肯定崩。
后来才发现，我一般建议把常见问题单独做一页。用户问的问题就那些，提前答了省很多沟通。细节往往就差在这。
文章之间互相链接，既方便用户也方便抓取，这活儿花不了多少时间。
图片用新格式能省不少体积。同样清晰度，文件大小能差出一大半。
本地团队的好处是能坐下来当面聊，有些事线上真说不清楚。
想被引用，内容得有明确的结论，模棱两可的那种很难被选中。
搜索友好的结构最好一开始就规划好，事后补代价很大。
说白了，用脚本动态生成内容的页面，抓取方不一定看得见，这点要测试。这块别偷懒。
收录是第一步。页面都没被收录，谈什么排名。去后台看看，有多少页面是没进索引的。
结构化数据听起来挺技术，实际上就是给内容加标签，让机器更容易看懂你在说什么。
电话和入口放在显眼位置，别藏在某个角落里。
说实话，第三方统计代码早点装上，上线就有数据，不用等。
关于价格，模板站几千块能搞定，定制开发一般要贵不少。主要差在设计和功能的工作量。
技术上的几件事
每年做一次整体检查：内容有没有过期、链接有没有失效、设计有没有过时。
我自己踩过，安全别不当回事，尤其是有表单和后台的站，定期检查一下没坏处。
要不要后台、要不要会员、要不要多语言，这些基础问题早点拍板。
先想清楚要什么
目标用户要想清楚。给年轻人看的和给中年人看的，设计和内容完全不同。
关于「大气」，我一般会追问具体指什么。是配色沉稳，还是排版留白多，还是图大。
先列旧站的毛病，再谈新站要什么，这个顺序比较靠谱。
真要动手的话，建议先把需求写下来，哪怕只有几行字。