beehiiv 最容易出问题的不是域名本身，而是域名、redirect、页面发布和 Search Console 其实是一条链，少检查一环就会把流量漏在路上。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
在 beehiiv 上做站，很多人以为“域名显示 Live 了”就算收工，结果上线后才发现旧链接断了、404 页面把订阅者丢掉了、GSC 没验证、sitemap 也没交，搜索入口和分享入口同时掉链子。beehiiv 的网站能力其实已经够用，但前提是把 web domain、redirect domain、redirect rules 和 Search Console 当成同一条上线链路去做，而不是分散处理。
适用场景
- 你把 beehiiv 当 newsletter 官网、内容归档站或增长入口。
- 你准备从旧 builder、旧博客或其他平台迁到 beehiiv。
- 你有自定义域名，想统一搜索入口、订阅入口和旧链接跳转。
- 你打算让每篇内容进入 Google，而不是只靠邮件分发。
不适用场景
- 你还没有发布网站页面，只是临时发邮件，不准备做公开站点。
- 你没有域名控制权，不能改 DNS，也不能验证 Search Console。
- 你的网站结构高度自定义，需要复杂服务器级重写逻辑。
- 你还在 legacy builder，却想直接套用 new Website Builder 的 redirect 行为。
先认清 beehiiv 域名链路的四个角色
beehiiv 官方把域名拆成几个角色：web domain 用来承接站点本身，redirect domain 用来把另一个入口转到主站，email domain 和 branded link 则更多影响发信与点击表现。站长最容易混淆的是 web domain 和 redirect domain。前者决定网站的主 URL，后者是为其他域名或根域名做导流，不该和主站冲突着指来指去。
官方当前流程里，设置自定义域名会一次性生成所需 DNS 记录，手动模式下总共会给出 12 条记录；如果你用的是 Entri，系统会尝试自动写入。无论走哪条路，最终验收都不是“已验证”三个字，而是页面真的已发布、域名状态为 Live、旧路径能被正确带过去。
准备材料
- 先决定主站地址：是 www、newsletter 子域，还是另一个专门子域。
- 确认是否还需要 redirect domain，把根域名或旧子域跳转回主站。
- 准备 DNS 权限，最好能同时查看 A、CNAME、TXT 冲突。
- 准备 GSC 账户，确保有权限新增 Domain 或 URL prefix property。
- 列出旧 URL 结构，判断哪些需要自动重定向，哪些需要手工规则。
步骤一：先选 web domain，再决定 redirect domain
beehiiv 官方很明确地建议，如果你的主域名还承载别的网站，web domain 尽量用子域名，例如 newsletter.domain.com 或 www.domain.com。这样做的价值不是保守，而是少掉大量根域名冲突和迁移成本。若你已经把一个子域用作 web domain，再考虑是否要把根域名或另一个子域做 redirect domain。
- 优先确定主站承载地址，也就是 web domain。
- 如果根域名本来就有公司官网，不要拿它硬替换成 beehiiv 站点。
- 需要导流时，再加 redirect domain，不要让一个域名既想做主站又想做跳板。
- 如果你用子域作为 web domain，官方推荐把根域名定向到主站，而不是反过来把主站拽回根域名。
步骤二：连接域名时，把 DNS 和发布状态一起看
beehiiv 的自定义域名流程并不只是填一个域名。你需要先在 Domains 流程里完成域名配置，再把生成的 DNS 记录真正落到服务商那里。手动模式会给你完整记录；Entri 模式则可能自动代填。但无论哪条路径，页面没发布好、域名没 Live、页面依赖路径没通，最终效果都还是坏的。
- 若你的域名服务商支持 Entri，可以先走自动模式，节省人工填写时间。
- 若不支持，就按官方生成的记录逐条手工加，特别注意同一主机名的 A/CNAME 冲突。
- 看到 Verified 还不够，继续确认 web domain 或 branded links 最终状态是否变成 Live。
- 域名完成后，回到 Website Builder 确认站点页面已经 publish；否则 subscribe、upgrade 等托管页可能显示异常。
步骤三：理解三类 redirect，不要把自动行为想得过强
beehiiv 当前有三类 redirect：自动、手动和 404 redirect。自动 redirect 只在 new Website Builder 里的 custom page 改 slug 时生效；它不会替你处理 default page 或 dynamic page，也不会替 legacy builder 自动补救。很多人最容易踩的坑，就是以为“我改了 URL，系统肯定都帮我跳好了”，实际上只有 custom page 在新 builder 里有这个待遇。
- 如果你改的是 custom page URL，系统会自动生成旧路径到新路径的跳转。
- 如果你迁的是旧站、日期目录或整组路径，就去 Redirects dashboard 手工建规则。
- 如果站里有大量旧文章路径，要优先考虑 wildcard，而不是一条条手写。
- 任何新规则写完都先测试，再改站内内链，不要边试边公开发链接。
步骤四：把 404 fallback 当兜底，不当主修复
404 redirect 的作用是减少死路，而不是掩盖配置错误。官方举得很直白：如果退订页或其他页面莫名落到 404，更可能是域名或页面发布配置有问题，而不只是缺少 redirect。正确做法是先查域名和页面状态，再决定是否加一个 404 fallback。
- 优先检查页面本身是否已发布、域名是否已连接正确。
- 确认是“找不到路径”而不是“站点没发布”。
- 需要兜底时，在 Redirects 里填完整 URL 作为 404 fallback，别只填半截路径。
- 如果是订阅或退订路径异常，优先修根因，再把 404 redirect 作为临时缓冲。
步骤五：用 wildcard 处理迁移，不要手工制造维护债
如果你手上有一批旧文章路径，wildcard 是比手工规则更稳的做法。beehiiv 的规则里星号匹配每一段 path，匹配结果会按 $1、$2 往后传。这个机制对日期目录、栏目迁移和文档目录改版很实用，但前提是你先用 Test patterns 验证，不要拍脑袋上线。
- 先把旧路径分组，例如 blog 路径或 docs 路径这种结构。
- 为每一组建立最小可用规则，再去 Test patterns 验证实际命中结果。
- 验证通过后，再统一调整站内旧链接、导航或邮件落地页。
- 如果某条路径不该被统配，就单独建一条更精确的规则，别让 wildcard 吞掉所有例外。
步骤六：GSC 验证别走错 property 类型
beehiiv 官方对 Search Console 的说明很细：如果你用的是 beehiiv 提供的默认域名，选 URL prefix；如果你用的是自定义域名，选 Domain。验证方式建议用 HTML tag，但不是把整段 meta 标签硬塞进 beehiiv，而是只取 content 里的验证码，放进 Website Builder 的 Pixels 设置，再回 GSC 点 Verify。
- 新增 property 之前，先复制最终对外的 publication URL。
- 自定义域名选 Domain，默认域名选 URL prefix，不要混着来。
- 在 HTML tag 验证里，只复制引号里的 verification code，不要把整段 meta 标签一起贴。
- 验证成功后，继续去 Sitemaps 提交 sitemap.xml，不要停在验证通过这一步。
可复制上线模板
主站 web domain：
redirect domain：
域名接入方式：Entri / Manual
DNS 冲突已检查：是 / 否
Website Builder 已发布：是 / 否
需要的 redirect 组：
- custom page 自动跳转
- wildcard 迁移
- 404 fallback
GSC property 类型：Domain / URL prefix
verification code 已写入 Pixels：是 / 否
sitemap 已提交：是 / 否
首轮复查日期：实际例子：把旧博客路径迁到 beehiiv 而不是一篇篇补救
一个创作者原来把文章放在独立博客上，后来决定让 beehiiv 承担新站点和订阅转化。但他如果只是把新域名连上，旧博客链接和社媒分享入口仍会继续掉流量。更稳的做法是：先用 newsletter.domain.com 做 web domain，把根域名做 redirect domain，再用 wildcard 把旧 blog 路径统一导到 beehiiv 新路径，最后在 GSC 验证 Domain property 并提交 sitemap.xml。这样旧链接不会一夜失效，新的索引也能慢慢接上。
验收清单
- web domain 和 redirect domain 的角色已经分清，不会互相打架。
- DNS 已完成，状态不只是 Verified，而是最终 Live。
- Website Builder 页面已发布，不会让托管页显示异常。
- automatic、manual、404 redirect 的使用边界已经分清。
- wildcard 规则已经过 Test patterns 验证。
- GSC 已完成验证，并提交 sitemap.xml。
常见坑
- 还在 legacy builder，却以为 custom page 自动 redirect 会替你全站兜底。
- 根域名本来有别的站，却强行拿来当 web domain。
- 规则刚写完就发出去，没有先在 Test patterns 里过一遍。
- GSC 复制了整段 HTML 标签，而不是只取 verification code。
- 域名状态已验证，但站点页面压根没发布。
排错路径
- 域名已 verified 但页面不对：先回 Website Builder 看页面是否已 publish。
- redirect 没生效：先确认这是不是 new Website Builder 的 custom page。
- 路径规则乱跳：用 Test patterns 查命中的是哪一条规则。
- GSC 无法验证：检查 property 类型是否选错，verification code 是否只保留引号里的值。
- 404 仍然频繁：先查页面和域名配置，再决定是否继续扩充 fallback。
后续维护建议
更新日期：2026-07-29。beehiiv 的网站能力对创作者来说已经足够强，但最怕的是把域名、重定向和索引拆开做。只要每次改路径都同步做 redirect 测试、每次换域名都复查 Builder 发布状态、每次大改结构都回 GSC 看 sitemap 和覆盖情况，这套站点会比“只求先能打开”稳很多。