最近花了两周时间，做了一个面向美国用户的 bra size 计算器： /ai-market-guide/ 整个站是纯静态的，没有后端、没有数据库，部署在 Cloudflare Pages 上。目前做了四个页面，核心功能就是根据用户输入的身体围度，计算一个参考内衣尺码。
做这个项目的初衷很简单：想试试用一个足够轻量的工具站，从关键词研究、页面设计到计算逻辑，再到 SEO 部署，完整跑一遍流程。记录一下过程中比较值得分享的几个地方。
一、为什么选这个方向？一开始并没有直接写代码，而是先看关键词。
美国用户搜索内衣尺码相关问题时，会涉及很多不同的搜索意图，比如： bra size calculator band size calculator sister size calculator bra size conversion 这些词看起来都和同一个需求有关，但用户真正想解决的问题不完全一样。主词的竞争通常比较激烈，成熟的大站已经有相对完善的页面、外链和品牌积累。
新站如果一上来就想竞争最宽泛的关键词，可能很长时间都没有什么结果。所以我选择先从细分需求入手。
比如，有的人只想知道自己的下胸围应该对应什么 band size；有的人已经知道自己的尺码，只是想找姊妹码；还有的人想弄明白英寸和厘米之间的换算。这些需求虽然相关，但完全可以分别设计页面，让每个页面尽量解决一个明确的问题。
这里也不是说长尾关键词一定比主词容易做，而是对于一个没有太多资源的新站，先把具体需求研究清楚，比直接冲最热门的词更有操作性。关键词研究最后还是要回到搜索结果本身：看看现有页面解决了什么问题、有没有信息缺口，以及自己能不能做出更清晰、更方便使用的工具。
二、尺码计算逻辑，比写页面麻烦多了 这是整个项目里我觉得最值得花时间研究的部分。内衣尺码计算并不是简单地把两个数字相减，再查一张表就完事了。
不同品牌、国家和计算体系可能存在差异，如果直接照搬网上的一张旧表，很容易出现结果看起来合理、实际上却不太对的情况。我在实现时，主要处理了下面几个问题。
- 统一计算单位 内部计算以英寸为基准。如果用户输入的是厘米，先转换成英寸： inches = cm / 2.54 这样后续的 band、bust 和 cup 计算都使用同一套单位，避免在不同单位之间反复计算造成误差。
显示结果时再根据用户选择的单位进行转换。 2. Band size 怎么取？
这里采用下胸围取最近偶数的规则。例如，下胸围测量值是 31 英寸，按最近偶数取值会得到 32 band。
这个步骤看起来简单，但需要注意测量值处于两个偶数中间时的处理方式，以及输入精度和四舍五入规则，否则不同页面可能算出不同结果。 3. Cup size 怎么算？
基本思路是用上胸围与下胸围之间的差值作为参考： 差值 = 上胸围 − 下胸围 然后根据差值映射到对应的罩杯。我采用的映射规则中，差值小于 1 英寸时对应 AA，后续再按照设定的区间映射到其他罩杯。
这里需要强调一点：这是一套明确的计算规则，不代表所有品牌都使用完全相同的尺码体系。实际穿着效果还会受到品牌版型、胸型和测量方式的影响。
- 姊妹码怎么换算？姊妹码（Sister Sizes）的基本规律是： Band 增加 2，Cup 字母通常向下调整一级。
Band 减少 2，Cup 字母通常向上调整一级。例如，34C 的姊妹码通常包括 32D 和 36B。
原理是通过调整下胸围，同时调整罩杯容积，使不同尺码之间尽量保持接近的罩杯容量。实现时不能只做字符串替换，还要处理罩杯字母的顺序、边界情况，以及不同尺码体系的差异。
- 最麻烦的是 plus-four 算法 我在研究旧尺码表时，发现一个很容易造成误判的问题：plus-four 算法。一些传统计算方法会先根据下胸围增加 4 英寸，再推算 band size。
这会产生一个很明显的差异：29–30 英寸的下胸围，经过某些旧式规则处理后，可能会被归到 34 band。如果用户习惯的是不额外加 4 英寸的现代测量方式，这个结果就可能让人困惑。
因此，我没有直接把网上找到的旧 chart 当成唯一标准，而是明确采用自己的计算规则，并尽量让输入、换算和结果展示遵循同一套逻辑。这也是我觉得工具站开发中很容易被低估的一件事：代码本身可能只需要几十行，但你得先搞清楚自己到底在实现哪一种规则。
三、为什么选纯静态 + Cloudflare Pages？目前整个网站使用纯静态页面，没有专门的后端服务，也没有数据库。
选择这套方案，主要有几个原因： 计算可以在浏览器本地完成。用户输入围度后，直接通过 JavaScript 计算结果，不需要把数据发送到服务器。
部署简单。页面构建完成后直接部署到 Cloudflare Pages，不需要维护服务器、数据库和 API。
访问速度和维护成本比较友好。对于计算逻辑简单、数据量不大的工具站，没有必要为了技术架构而增加复杂度。
另外，页面里的图形尽量使用内联 SVG，而不是随便找一些模特照片或者商品图片。一方面是版权问题，另一方面是工具本身也不需要大量照片才能完成任务。
如果以后考虑接入 AdSense，图片版权和页面内容质量也值得提前考虑。不过，使用 SVG 并不意味着自动符合 AdSense 政策，最终还是要看整个网站的内容质量、实用性和政策合规情况。
对这种小型工具站来说，我更倾向于先把核心功能和页面体验做好，而不是先堆很多视觉元素。四、部署和 SEO 过程中踩过的坑 纯静态站不代表上线就万事大吉，域名和搜索引擎相关的细节也需要处理。
- www 和裸域的统一 例如： brascale.com www.brascale.com 如果两个地址都能正常访问，却没有统一的规范域名，可能会给网站的索引和维护带来不必要的复杂性。所以需要明确一个主域名，并将另一个域名通过 301 重定向过去。
这里要注意，不只是首页，其他页面的路径也应该正确保留，避免所有地址都被错误地重定向到首页。 2. Sitemap 和规范 URL Sitemap 需要列出希望搜索引擎发现的规范页面地址，并且确保这些地址实际可以正常访问。
我在处理 URL 时也特别关注了尾斜杠的一致性。严格来说，sitemap 并不是必须全部带尾斜杠，而是要和网站实际使用的规范 URL 保持一致。
如果 /page 和 /page/ 的处理不统一，就可能出现重复 URL、重定向链或者错误的规范地址。因此，最好提前确定 URL 规则，再统一处理页面内部链接、canonical 标签和 sitemap。
- 纯静态网站也需要考虑 SEO 工具站很容易出现一种情况：功能确实能用，但搜索引擎看到的页面内容非常少。所以每个页面除了计算器本身，还需要清楚地解释： 这个工具解决什么问题； 输入的数据应该如何测量； 计算结果是怎么得出的； 结果有哪些局限； 用户接下来可以做什么。
这些内容不只是为了 SEO，也是为了让用户真正理解计算结果。五、接下来准备观察什么？
网站上线只是第一步，接下来更值得关注的是实际数据。我比较关心几个问题： 细分关键词能不能带来真实的搜索流量； 用户更常使用主计算器，还是某个具体的细分工具； 搜索用户进入页面后，是否真的完成计算； 哪些页面值得继续投入时间优化。
对小工具站来说，开发完成并不意味着项目验证成功。真正重要的是能不能找到明确的用户需求，并通过搜索流量持续获得用户。
如果最后发现某些关键词没有流量，或者用户需求和预期不一致，也需要根据数据调整，而不是不断增加功能。目前先把第一版跑起来，后续再根据真实反馈迭代。
网站放这里： /ai-market-guide/ 如果大家也做过面向海外用户的纯静态工具站，尤其是通过 SEO 获取自然流量的，欢迎交流一下：你们通常会先做一个覆盖面比较广的主工具，还是先从几个具体的长尾需求切入？