网站只有100个页面，需要提交Sitemap吗？
需要，但理由跟大多数人想的不一样。
100 个页面这个规模，爬虫从首页顺着内链走两三跳就能全部摸到。sitemap 在"被发现"这件事上几乎不加分——一个连内链都没做通的 100 页站点，加了 sitemap 也救不回来。真正值得提交的是另外三件事。
lastmod 是 Google 唯一愿意信的更新信号
sitemap 里那个 <lastmod> 字段，Google 用它决定要不要重新抓取某个页面。前提是它必须真实、可验证、符合 W3C Datetime 格式（2026-09-24 这种日期，或者带时区的时间戳）。
我见过最多的问题是构建脚本每次都把所有 URL 的 lastmod 写成当天。这种写法用久了，Google 会发现这个字段毫无信息量，然后整份忽略——等于你主动放弃了唯一一个能主动告诉搜索引擎"这页改过了"的通道。
正确做法是让它跟文件在 Git 里的真实修改时刻绑定，构建时读出来写进去。静态站生成器通常有现成插件做这件事，自己实现也就是一条 git log -1 --format=%cI -- <file>。
不提交 sitemap，你根本看不到有多少页面被拒绝
Search Console「网页」报告里那两类状态——“已发现 – 尚未抓取"和"已抓取 – 目前未编入索引”——只有在提交过 sitemap 之后才会成系统地出现。
100 页里有 30 页没进索引，是很常见的比例。不提交 sitemap，这 30 页会安静地躺在某个角落，你只会觉得"这个站怎么没流量"，永远定位不到具体是哪 30 页。sitemap 在这里的作用是一份待核对清单，不是通行证。
100 页不需要分片，但要知道阈值在哪
Google 对单份 sitemap 文件的硬限制是 50,000 条 URL、未压缩 50MB。100 页离这个上限差 500 倍，所以答案很干脆：一个 sitemap.xml 就够，别搞 sitemap index，别按类型拆。拆了只会多一个要维护的东西。
需要分片的是几万页的站。Sitemap 与 robots.txt 那一节讲了完整的格式规范和索引文件写法，提前看一遍能省掉后面的返工。
changefreq 和 priority 两个字段 Google 早就公开说过不采用，输出它们只是增大文件体积，可以省掉。
sitemap 里只放能进索引的 URL
规则其实只有一条：每一条都必须是 canonical、能被抓取、且没有 noindex 的绝对 URL。翻过来就是三个高频错误。
放了被 robots.txt 挡住的 URL——Google 会报"无法访问"，这类报错积累多了会影响整份文件的可信度。放了带 ?utm_source= 这类跟踪参数的地址——它不是 canonical 版本。放了 301 跳转之前的旧地址——这条最隐蔽，因为旧地址往往还在数据库里。
生成完之后自查一遍：拿 sitemap 里随机十条 URL，curl 一下看返回码是不是 200、页面上的 canonical 是不是等于这个地址本身。十分钟能查完。
交付方式就两行
robots.txt 顶部写一行 Sitemap: https://example.com/sitemap.xml，然后在 Search Console 里提交一次。
动态生成的话，用 Nginx 把 /sitemap.xml 反代到生成服务，或者直接指向静态文件都可以，但要确认响应头是 application/xml 而不是 text/plain——后者会被当成普通文本忽略掉。这个坑在默认配置里很容易踩到，尤其当 sitemap 是由某个后端接口吐出来的时候。
像 10015.io 那种用 Next.js 做的站，50 多个工具页面由框架路由自动产出 sitemap，100 页量级完全够用，没必要自己写生成器。等哪天页面数到了四位数，再自己接管也不迟。
10015.io 首页把 Product Finder 放在 Explore Tools 旁边，先描述需求再找工具的路径成了显性入口。
提交完之后等什么
24 小时内看"已发现"的计数有没有涨，一周内看"已编入索引"有没有开始动。
一周后索引数还是 0，别急着改 sitemap，先去 URL 检查工具里手动跑一条。它返回的如果是抓取错误（404、5xx、robots 拦截），那是配置问题，改完立刻见效；如果是"已抓取 – 目前未编入索引"，那是内容判定问题，改 sitemap 完全没有用。这两条路的处理方式完全不同，先分清再动手。
Google sitemap 5 万条 URL / 50MB 上限引自 Search Central 官方文档；10015.io 技术选型（Next.js + styled-components、50+ 工具）来自其公开说明。