Vue 3 + Vite 图片工具的 SEO 实践：从路由元数据到预渲染的完整方案

一、每个搜索意图都需要独立 URL

“在线图片转换”和“在线图片压缩”虽然共享上传组件，但搜索意图、标题和说明完全不同。LemonArt 使用 /zh/convert、/zh/compress、/zh/edit、/zh/repair 等路径，让每个功能有稳定 canonical、独立 description 和关键词集合。博客文章再使用 /zh/blog/slug 承接长尾技术查询。

• 工具页：解决用户立刻要完成的图片操作。
• 博客页：解释实现原理、兼容性和选择方法。
• 详情页：围绕一个明确问题提供完整上下文。
• 相关工具链接：把信息流量自然导回可操作页面。

二、动态 meta 还需要服务端内容

客户端路由可以在切换页面时更新 title、description、Open Graph 和 canonical，但搜索引擎第一次请求时可能只看到基础 HTML。LemonArt 的 SSR 入口会根据请求路径生成对应应用，并在 prerender 脚本中把工具页和博客页写入 dist，部署到 Cloudflare Pages 后直接返回完整 HTML。

标题与描述的长度需要按语言分别打磨，而不是机械翻译。LemonArt 的完整标题由站点名与页面标题拼接，中文页如“LemonArt · 免费在线图片格式转换器：PNG、JPG、WebP、AVIF 等 14 种格式互转”控制在 50-60 字符，描述标签在 150-160 字符左右，覆盖格式列表、能力范围与本地处理等用户最关心的信息；英文页在同一长度约束下调整措辞，日文页还要考虑假名与汉字混合的阅读节奏。

• title 标签按完整渲染结果（含站点名前缀）控制在 50-60 字符。
• description 控制在 150-160 字符，CJK 页面因字符宽度更接近截断上限，不必硬凑长度。
• 每个页面独立检查标题与描述的唯一性，避免三个语言版本共用同一段文案。
• 元数据变更后重新预渲染，并抽查 dist 产物中的 title、og:title 与 JSON-LD 是否一致。

const documentHtml = template
  .replace('<!--app-html-->', appHtml)
  .replace('<!--seo-title-->', escapeHtml(route.meta.title))
  .replace('<!--seo-jsonld-->', JSON.stringify(schema))ts

三、技术博客为什么要用 BlogPosting 数据

文章详情页使用 Article 或 BlogPosting 结构化数据，明确 headline、description、datePublished、dateModified、author、mainEntityOfPage 和 image。结构化数据不能保证搜索结果一定出现富摘要，但能帮助搜索引擎理解页面类型和文章实体。正文仍然需要真实、有层次、能解决问题，不能只堆关键词。

具体到字段，LemonArt 的 JSON-LD 按三部分组织：WebSite 与 Organization 描述站点实体，BlogPosting 描述文章本体，BreadcrumbList 提供层级上下文。文章的 dateModified 必须与页面实际更新时间一致——内容改过、日期没更新，会让结构化数据与正文互相矛盾。

需要注意的坑是 image 字段：富摘要对图片尺寸有要求，站点统一使用固定的 4:3 封面资源，避免每篇文章配置不同尺寸的图片导致部分页面无法展示摘要。

四、内部链接和关键词要服务用户

每篇文章会链接到相关的 LemonArt 工具，例如 OpenCV.js 修复文章链接到图像修复板块，压缩原理文章链接到图片压缩页面。锚文本直接说明目的，避免大量“点击这里”。文章中的关键词使用自然变体：图片压缩、WebP 压缩、浏览器本地处理、OpenCV.js 图像修复等，围绕同一主题形成语义覆盖。

五、发布后的技术检查

SEO 不是只改 title。每次发布都应检查预渲染 HTML、canonical 是否唯一、sitemap 是否包含新文章、robots 是否允许抓取、移动端标题是否截断、Open Graph 图片是否可访问，以及工具页面的核心交互是否仍然可用。技术指标和内容质量共同决定长期效果。

内容更新后还要同步日期字段：publishedAt 与 updatedAt 会写入 BlogPosting 结构化数据，真实反映文章的新鲜度。文章被重新发布时更新 updatedAt 并重新预渲染，sitemap 的 lastmod 也会随构建刷新，方便搜索引擎判断何时值得重新抓取。

• 每次发布后抽查 title、description 与 og:title 的渲染长度。
• 发布新版本时更新 updatedAt，让结构化数据与页面内容保持一致。
• 用 Bing Webmaster 等工具跟踪点击率与搜索排名，定期复审标题和描述。
• 移动端结果中标题同样会截断，按字符数与像素宽度双重校验。

六、把元数据审计固化到构建流程

人工逐页检查元数据在小站点可行，但会随页面数量增长而失效。LemonArt 的做法是把审计写进发布脚本：构建完成后遍历 dist 目录下的每个 HTML，断言标题长度落在 50-60 字符、描述长度不低于下限、同一路由下 title 与 description 不重复、canonical 唯一，任一断言失败就让构建报错。这样标题和描述被改短、漏翻译或复制错页时，问题在发布前就会被拦住。

审计脚本读取的正是构建产物而不是源码，这很关键：它验证的是搜索引擎真正拿到的 HTML，包括 prerender 替换后的 title、og:title 与 JSON-LD，而不是源码里可能已过期的占位符。语言维度上，中、英、日三套文案各自独立校验，避免某一种语言漏更新。

for (const file of walkDistHtml()) {
  const title = readTitle(file)
  const description = readDescription(file)
  assert(title.length >= 50 && title.length <= 60, `${file}: title ${title.length}`)
  assert(description.length >= 140, `${file}: description too short`)
  assert(isUnique(title) && isUnique(description), `${file}: duplicated meta`)
}
console.log(`Audited ${count} pages: title/description/canonical OK`)ts