核心用法
wp-to-static 是一款专为 WordPress 站点静态化迁移设计的自动化工具。用户需提供 SSH 连接信息(主机、端口、用户名、密钥路径)和目标站点 URL,工具即可在远程服务器执行 wget --mirror 抓取渲染后的 HTML,通过 rsync 同步静态资源至本地,经多轮处理后部署至 Cloudflare Pages。
完整流程包含十个严格阶段:环境验证 → SSH 连通性测试 → 定位 WordPress 安装目录 → 服务器端镜像抓取 → 安全 rsync 同步(排除所有 PHP/配置文件)→ 智能资源提取(仅保留 HTML/CSS 实际引用的文件)→ URL 修复与字体自托管 → WordPress 特征清理 → 本地验证 → 安全部署。关键创新在于第 5 步的资源提取算法,通过解析 HTML 的 src//href//srcset 属性和 CSS 的 url()() 引用,将典型 1.5GB+ 的 WordPress 站点精简至约 25MB。
显著优点
极致性能提升:静态站点消除 PHP 运行时和数据库查询,配合 Cloudflare 全球 CDN,实现毫秒级首字节响应。
零攻击面:移除所有服务器端代码(PHP、wp-config、.htaccess),彻底杜绝 SQL 注入、RCE、插件漏洞等传统 WordPress 攻击向量。
零托管成本:Cloudflare Pages 提供免费无限带宽静态托管,适合个人博客、企业官网、文档站点。
安全设计严谨:强制 SSH 主机密钥验证(禁用 StrictHostKeyChecking=no)、ssh-agent 密钥管理、部署前强制清理构建目录、GitHub 私有仓库默认,形成纵深防御。
像素级还原:保留原始站点的视觉和交互效果,仅移除 WordPress 元数据(generator、EditURI、wp-json 等)。
潜在缺点与局限性
动态功能丧失:表单提交、搜索、评论、会员系统等动态功能需替换为第三方服务(如 Formspree、Disqus)或完全移除。
更新流程复杂:内容更新需重新执行完整流程,无法像传统 WordPress 那样即时发布,适合更新频率低的站点。
环境配置门槛:需预先配置 6 个必需环境变量、GitHub CLI 和 Cloudflare Wrangler 认证,对非技术用户不够友好。
服务器依赖风险:首次镜像需在远程服务器执行命令,若服务器不可信或配置不当,存在供应链风险。
边缘场景覆盖不足:重度依赖 JavaScript 的交互功能(如 WooCommerce 购物车)可能无法正确静态化。
适合的目标群体
- 安全敏感型用户:希望彻底消除 WordPress 漏洞风险的企业官网、政府站点
- 成本敏感型用户:个人博客、非营利组织、初创公司,追求零托管费用
- 性能极致追求者:需要全球秒开的高流量内容站点
- 归档备份需求:将历史 WordPress 站点转为永久静态存档
- DevOps 工程师:具备 SSH/CI/CD 经验,能自动化集成至发布流程
使用风险
配置错误风险:环境变量配置不当可能导致连接失败或部署至错误项目,建议首次使用 --dry-run 模式(如未来支持)。
SSH 密钥泄露:若未使用 ssh-agent 而将密钥密码硬编码,或在不安全环境记录命令历史,可能导致凭证泄露。
资源提取遗漏:复杂的懒加载、JavaScript 动态注入资源可能被误判为未引用而删除,需部署前仔细验证。
构建目录残留风险:尽管 Skill 强制在 git 操作前删除 ./build/,若用户手动中断流程或修改代码,仍存在敏感文件误提交可能。
供应商锁定:深度绑定 Cloudflare Pages 和 GitHub,迁移至其他平台需调整部署逻辑。