Day 27｜我翻了GitHub上30个开源模板，90%连Google都读不懂

挑开源模板不是看它好不好看，是看Google能不能看懂它。

我有个习惯——看到开源项目就 star。GitHub 收藏夹里躺着几百个 Next.js 模板，从 SaaS 启动器到博客主题，从 landing page 到工具站全套。收藏的时候脑子里的想法都一样：「下次做新站直接 fork，省一个月。」

我真去翻了。

一个一个打开，看 README，看 demo，看源码里的 metadata 配置。30 个模板翻下来，结论很直接：大部分开源模板的 SEO 默认配置，等于在 Google 面前裸奔。

一个拿了 2000 多 star 的 SaaS starter，metadata 只设了个空 title。另一个挂着「SEO optimized」标签的博客模板，canonical 标签根本没写，Google 会把它的每一篇文章都当独立重复页面。还有一个模板的 og:image 路径是相对路径——Twitter 卡片永远显示空白。

这些模板做对了 UI、做对了响应式、做对了暗色模式。唯独做错了 Google 最在意的那件事。

Google 最近两个更新，把这件事变成了致命伤

今年 Google 发了两个核心更新。

第一个是 3 月 27 日的 March 2026 Core Update。这次更新的核心信号叫「Information Gain」——Google 开始评估你的页面相比现有搜索结果，到底提供了多少新信息。与此同时，被标记为「模板化 AI 大规模生产」的内容，收录率暴跌 30-50%。

模板生成的页面 + 没改过的默认 SEO 配置 + 跟别人一样的结构和措辞——这在 Google 眼里就是最典型的「模板化内容」。

第二个是 5 月 21 日上线的 May 2026 Core Update。这次更新叠加了 AI Mode 和 Gemini 驱动的搜索结果页改造。Google 不再只看你「排第几」，还看你的内容「有没有资格被 AI 引用为来源」。判断标准里有一条：Schema 结构化数据的准确性和完整性。

偏偏大部分开源模板的 Schema 要么没写，要么写了但字段是空值。

两个更新叠在一起，结论很明确：你用模板不修 SEO，Google 不但不收录你，连把你当信息源引用的资格都不给。

我翻了 30 个模板，最常见的 5 个 SEO 致命伤

第一，metadata 是空的或者半残。

Title 和 description 是 Google 搜索结果里你的门面。App Router 的 Metadata API 很好用，但模板作者通常只写了个项目名做 title，description 直接留空。你的工具站上线后，Google 搜出来的结果就是「My App」加一段从 body 里随机抓的文字。

第二，没有 canonical 标签。

这个最隐蔽。很多模板的首页、分类页、标签页用的是同一个 layout 组件。没有 canonical 标签告诉 Google「哪个是主版本」，Google 就会判定这些页面互相重复，优先不收录。

第三，结构化数据是摆设。

Schema.org 的 JSON-LD 是 Google 理解你页面内容的「说明书」。工具站至少需要 WebSite + SoftwareApplication 两种 Schema。我翻的 30 个模板里，只有 2 个有基本的 Schema 配置，而且字段填得潦草。

第四，og:image 是相对路径。

这个不是 SEO 排名的直接因素，但它决定你的链接在 Twitter、Facebook、微信里长什么样。相对路径的 og:image 在所有社交平台都是失效的——你分享出去永远是一张灰底白字的默认卡。

第五，sitemap 要么没有，要么是静态手写的。

Next.js 支持动态生成 sitemap，新页面自动追加。但很多模板压根没配，或者给你一个手动维护的静态文件。你的工具站每上线一个新功能页面，都得去手动改 sitemap——这件事坚持不了一周。

两个真正 SEO 友好的开源项目

翻完 30 个之后，我找到两个值得推荐的。判断标准不是 UI 好看、不是 star 多，而是：fork 下来之后，不用修 SEO 就能直接被 Google 正确索引。

第一个：Tailwind Nextjs Starter Blog

GitHub 地址：github.com/timlrx/tailwind-nextjs-starter-blog，6000+ star。

这是专门给博客和内容站设计的 Next.js 模板。它做对了什么：

• • metadata 是完整的。 每篇文章自动生成 title、description、og:image、canonical。你只需要在 frontmatter 里填文章信息。
• • JSON-LD 结构化数据内置。 支持 BlogPosting Schema，字段自动从文章 frontmatter 提取，不用手写。
• • sitemap 和 RSS 自动生成。 新文章发布后自动追加到 sitemap.xml 和 RSS feed。
• • MDX 支持。 文章用 Markdown 写，能嵌入 React 组件——工具站的内容页面和交互组件可以共存。

适合做什么：工具站的博客区、产品更新日志、SEO 内容页。如果你做的是「内容型工具站」（比如阅读量计算器 + 教程博客），这个模板是从地基开始就 SEO 友好的。

第二个：Next.js SEO Starter

GitHub 地址：github.com/sazmco/nextjs-seo-starter。

这个是专门为 SEO 优化从头设计的 Next.js 启动模板。跟上面那个博客模板不同，它的定位更通用：

• • sitemap 自动生成。 新页面自动追加，不用手动维护。
• • robots.txt 可配置。 支持按路由规则区分哪些页面允许爬虫、哪些屏蔽。
• • canonical URL 内置。 每个页面自动生成 canonical 标签，防止重复内容问题。
• • JSON-LD 结构化数据预留。 提供了 schema 注入接口，WebSite / SoftwareApplication 类型只要填字段。
• • OpenGraph + Twitter Card 双支持。 metadata 配置到位，社交分享预览卡不会空白。

适合做什么：工具站的主站、产品 landing page、SaaS 营销站。它没带 auth、没带 payments、没带 dashboard——正因为专注 SEO，所以这部分的配置是全的。

5 分钟修复清单（不管你用什么模板）

如果你已经用某个模板搭好了工具站，不想从头换，下面这 5 个检查项可以直接套用。一个终端窗口 + 5 分钟，能修掉 90% 的问题。

1. 查 metadata（30 秒）

打开你的首页源码（View Page Source），搜 <title>。如果内容是「My App」「Next.js App」这种占位符——改掉。title 格式建议：「工具名 - 一句话功能描述」。

搜 <meta name="description"。没有就加，有但内容是通用模板文字就改。description 控制在 140-160 字符。

2. 加 canonical（30 秒）

在你的 layout 组件里加一行：

export const metadata = {
  alternates: {
    canonical: 'https://你的域名.com/当前路径',
  },
};

如果是 App Router，用 generateMetadata 动态生成。这一行让 Google 知道你的首页就是首页，不是首页?ref=xxx 那一堆变体。

3. 修 og:image（1 分钟）

打开 metadataBase 配置：

// app/layout.tsx
export const metadata = {
  metadataBase: new URL('https://你的域名.com'),
};

然后 og:image 用绝对路径：/og-image.png 会被自动补全。这一行修好，你的链接在所有社交平台都能正确展示预览卡。

4. 补结构化数据（2 分钟）

一个工具站最少需要两种 Schema：WebSite（告诉 Google 你是谁）和 SoftwareApplication（告诉 Google 你是做什么的）。

在首页 page.tsx 注入一个 JSON-LD：

<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{
    __html: JSON.stringify({
      '@context': 'https://schema.org',
      '@type': 'WebSite',
      name: '你的工具名',
      url: 'https://你的域名.com',
    }),
  }}
/>

工具页同理，用 SoftwareApplication 类型。字段不用全填，但 name、applicationCategory、operatingSystem 这三个必须写。

5. 检查 sitemap（1 分钟）

访问 https://你的域名.com/sitemap.xml。如果返回 404 或者内容是手写的那几条——用 Next.js 的 generateSitemaps 替换。

// app/sitemap.ts
export default function sitemap() {
  return [
    { url: 'https://你的域名.com', lastModified: new Date() },
    // 遍历你的工具页面和内容页，动态生成
  ];
}

配好这 5 项，你的模板就从「Google 读不懂」变成「基本能读」。

这件事的本质

不是模板不好。模板本身是中性的——它帮你省的是「把 div 拼成页面」的时间，不是「让 Google 理解你在做什么」的时间。

March 2026 更新之后，Google 的判断逻辑变了。它不再看你是不是「用了模板」，而是看你「在模板上做了什么」。一个 fork 完就上线、连 title 都没改的工具站，跟一个在原模板基础上修了 metadata、加了结构化数据、配了 sitemap 的工具站，Google 能分得清。

分得清的后果就是：前者不收录，后者收录。

所以回到开头的结论：挑模板的第一标准不是 UI 好不好看，是 fork 下来之后，Google 能不能读懂它已经有的东西。修 SEO 永远比从头写模板快——前提是你挑的模板底子是好的。

出海工具站90天实战系列，日更中。