接手一个WordPress网站，先别按插件数量决定删什么。更有价值的问题是：安装包来自哪里、目前是哪一版、哪个业务还依赖它、谁负责更新，以及出错后如何恢复。插件名看着熟悉，不代表安装文件来自原开发者；名字陌生，也不能直接认定为恶意程序。
先把后台列表变成可追溯的资产清单
逐项记录插件名称与目录标识、版本、启用状态、下载来源、开发者支持入口、用途、维护人和最后一次已知变更时间。付费插件另记授权归属和续费负责人，密钥保存在现有安全凭据系统，不要贴进共享表格。
“用途”不能只复制插件介绍。例如，表单插件应写明哪几个询盘页正在使用、通知发给谁；图片插件要确认是否改写历史媒体文件；SEO插件要确认实际输出标题、canonical和索引指令的范围。这样才能看出两个插件是在配合，还是同时改同一个结果。
普通插件列表也不是全部运行代码。让维护方说明是否存在必须使用的插件、主机提供的特殊组件或自定义代码，以及它们通过什么渠道更新。不要把没有出现在常规启用列表里的代码一律视为入侵，也不要因此忽略它。
把“待确认”与“立即处理”分开
- 来源清楚、用途明确：保留在清单中，核对当前维护与兼容状态，安排必要更新和回归。
- 没人说得清用途：先查页面、计划任务与业务依赖，再在隔离环境验证移除影响。暂时停用不等于文件已经删除。
- 来源无法追溯或文件变化异常：保存相关版本、变更记录与日志，交给具备权限的人员调查。发现可疑内容后直接覆盖文件，可能丢掉判断入口。
最近没更新只是需要追问的线索，不是“已中毒”的证据；反过来，安装量大也不是安全保证。WordPress官方安全加固文档强调可信来源、保持更新、删除不用的插件及可靠备份，目标是降低风险，并未承诺彻底消除风险。
要理解来源、维护状态和前台输出之间的关系，可以继续看光算的WordPress插件供应链风险检查。插件运行的是服务端代码，不能仅凭“没弹出权限请求”就推定它没有能力影响页面或数据。
删除之前，先证明能恢复
保存文件和数据库的一致备份，并确认恢复流程可用。对已确认不需要的插件，在合适的测试环境检查移除后是否留下短代码、空白模块、缺失字段或无法提交的表单，再安排正式操作。某些卸载过程会删除数据，不能假设重新装回插件就能恢复原状态。
交接结束时，把首页、典型详情页和关键业务入口的测试结果一并留下。正常显示不代表安全调查已经完成，但它能说明本次清理有没有破坏业务。下一位管理员应能从清单知道谁批准了变更、改了什么、还有哪些异常未确认，而不必重新猜一遍。