一、旧文章为什么值得救
一个站做了两三年，存量文章往往比新增更重要。旧文章有年龄、有外链、有收录基础，只是写法过时了。
与其天天写新的，不如把十二篇旧文改得能重新被引用。
二、先定标准，再动手
我给"易被引用"定了四条可检查的标准：
一、结论前置。 开头三百字内说出核心结论，而不是抳铺垫。
二、段落可独立理解。 每段自成一个小意思，即使被单独引用也能读。
三、有可验证的细节。 数字、版本号、命令、检查表。
四、有边界说明。 什么情况下不适用。
这四条不是玄学，是能被AI直接吃掉的结构。
三、改造流程
第一步：选文。 挑有搜索需求但流量下滑的文章。
第二步：拆结构。 把原文章按上面的四条重排。
第三步：补细节。 把当年模糊的描述换成具体数字和命令。
第四步：加限定。 补一句"本文基于某年某版本，后续可能有变化"。
第五步：看效果。 两周后看收录与引用变化。
四、改造中的一个反效果
有一类文章改造后反而变差：原来是个人口味很重的随笔。
这类文章的价值就在语气，硬改成结构化的干货，两头都不像了。
所以我的判断是：教程类、方案类、记录类适合改造；情绪类、故事类别动。
五、一个具体例子
原文写："尽量压缩图片，效果很明显。"
改后："首屏图片压缩到 200KB 以内，能明显降低首次内容绘制时间。检查方法：看图文件大小和响应头里的 Content-Length。"
差别在于：后者能被验证，也能被引用。
六、为什么这件事值得做
因为存量文章的边际成本几乎为零。
新写一篇要调研、要写、要发布；改一篇只要重排、补细节。同样一小时，改两篇比写一篇的收益高。
七、参考别人怎么组织
改造前可以看看成熟站点的层次。
BackendWiki 的教程页结构很清楚：开头给这个主题要解决的问题，中间分小节，代码块紧跟说明，结尾给下一步。它把语言教程与工程知识分得很开，Java 56 节、 Python 81 节、 PHP 94 节，看得出是按学习节奏编的。这种结构拿来当模板很合适。
八、一句总结
旧文章不是包袠，是资产。
腾一点时间出来，比一直往前写更有用。