Substack 和 beehiiv 都能收订阅者，但它们不是同一个邮件环境。Substack 的网络推荐和付费订阅关系，到了 beehiiv 之后会变成更传统的 ESP 运营问题：名单来源、发件域名、标签、自动化和投诉率都要重新看。
2026 年 Reddit 上有一个迁移案例很典型：作者把约 1.5 万 Substack 订阅者搬到 beehiiv，迁移初期打开率还能维持在 49%-50%，随后因为发信频率从每周 3 次升到 5 次，deliverability 和读者反应开始出问题。这个案例不能代表所有账号，但足够提醒一件事：迁移当天不要顺手改频率、改定位、改销售节奏。
迁移前先导出哪几份文件？
先做两类导出。订阅者名单走 Substack 的 Subscribers 页面，按免费、付费、活跃度和标签筛选后分别导出 CSV。整站备份走 Settings → Exports，生成包含文章、订阅者列表和相关统计的 ZIP。
不要只留一份清洗后的 CSV。原始导出、清洗文件、导入文件要分开保存。后面如果 beehiiv 拒掉一批邮箱，或者付费会员说权益没对上，你需要回到原始数据查加入时间、状态和来源。
| 文件 | 后台路径 | 必留字段 | 作用 |
|---|---|---|---|
| 全量订阅者 CSV | Substack → Subscribers → Export | email、status、paid/free、created date、来源标签 | 回滚和对账 |
| 付费会员 CSV | Subscribers 先筛 paid 再导出 | email、价格、周期、到期日、权益备注 | 防止权益断层 |
| 内容 ZIP | Settings → Exports → Create new export | posts、pages、stats | 迁移历史文章 |
| 清洗后导入 CSV | 本地表格 | Email 第一列、tags、custom fields | beehiiv 导入 |
| 迁移公告草稿 | Substack 旧平台 | 新发件人、域名、节奏变化 | 降低陌生邮件投诉 |
beehiiv 导入时哪些字段不能乱放？
beehiiv 的导入入口是 Settings → Subscribers Import → New Subscribers Import。CSV 可以上传，也可以粘贴邮箱列表。正式迁移用 CSV，别手动粘贴，因为你会丢掉标签、付费状态和来源。
beehiiv 帮助页写得很具体：Email 列必须是最左侧，且不能有空值；可接受的表头包括 email、email address、emailaddress。其他列要在导入过程中映射为 custom field 或 subscriber tag。已有订阅者的 tag 会叠加，custom field 则要注意是否覆盖旧值。
| CSV 列 | beehiiv 映射 | 迁移备注 |
|---|---|---|
| 必填，放第一列 | ||
| substack_status | Custom field | 保留 free、paid、comped、unsubscribed 的原状态 |
| source | Tag 或 Custom field | 区分 Substack organic、recommendation、manual import |
| created_at | Custom field | beehiiv 默认会把导入日期当订阅日期，原 signup date 要单独留 |
| paid_until | Custom field | 付费会员权益对账用 |
| engagement_bucket | Tag | active、warm、cold 分批发送 |
beehiiv 会在 Historical Imports 里显示 status、uploaded、accepted、rejected 等数字。导入后第一件事不是发信，而是把 rejected 记录导出，看看是重复、inactive、格式错误，还是名单质量问题。
付费会员怎么迁？
付费会员不要跟免费名单一起导入。Substack 的付费关系、发票、退款、赠送订阅和承诺权益，不能靠 beehiiv 一个 tag 解决。
最低限度要做一张付费会员表：邮箱、原订阅价格、币种、周期、当前到期日、是否赠送、最后一次付款时间、是否已通知。迁移后给付费会员单独发一封说明，写清楚旧订阅是否继续、是否需要重新绑定付款、历史权益在哪里看。
如果你准备把付款也切到 beehiiv，先找 5-10 个真实付费会员做小批量测试。别在没有跑通付款、退款和取消流程前，对全量会员宣布新平台上线。
域名、DNS 和首封邮件什么时候做？
域名至少提前 3-7 天处理。发件域名、DKIM、SPF、DMARC、品牌头像和 reply-to 邮箱都要先配好。迁移当天才改 DNS，后面就分不清是认证问题、名单问题，还是读者不认新发件人。
推荐时间线如下：
| 时间 | 动作 | 验收标准 |
|---|---|---|
| T-7 | Substack 全量导出和截图 | 原始 CSV、内容 ZIP、付费会员表都已保存 |
| T-5 | beehiiv 建 publication、配域名 | 发件域名认证通过，测试邮件能到收件箱 |
| T-4 | 清洗冷订阅者 | cold tag 单独保存，不进首批发送 |
| T-3 | Substack 发迁移公告 | 告诉读者新发件人和频率不变 |
| T-1 | 导入 5%-10% 活跃读者 | accepted/rejected 数字正常 |
| T+1 | beehiiv 发第一封说明 | 不销售，不加新频率，不突然换语气 |
| T+14 | 再看冷名单 | 根据投诉、打开和退订决定是否唤醒 |
迁移后 2 周最怕哪三件事？
第一是发信频率变快。迁移本身已经让读者面对陌生发件人，你再从每周 1-2 封变成每天一封，退订和投诉都会被放大。
第二是把 Substack 推荐来的弱关系读者当成强关系读者。Substack 的 Notes、推荐网络和关注不等于稳定邮箱打开。beehiiv 更依赖你自己的发送节奏和域名信誉。
第三是多人同时改后台。一个人改 DNS，一个人改 welcome email，一个人导入标签，最后谁也说不清哪一步影响打开率。如果团队同时管 Substack、beehiiv、域名和收款后台，可以固定一个管理员处理核心设置，用长期稳定家庭 IP + 单设备绑定承载后台操作，编辑和商务只在表格里提交变更。
迁移表怎么记录？
把迁移记录做成一张表，而不是散在聊天记录里。每次导入都要能复盘：哪份 CSV、多少 uploaded、多少 accepted、多少 rejected、哪些 tag、谁操作、截图编号是什么。
| 批次 | 名单范围 | 导入人数 | accepted | rejected | 发送动作 | 下一步 |
|---|---|---|---|---|---|---|
| A | 近 90 天打开读者 | 1000 | 980 | 20 | 迁移说明 | 看投诉率 |
| B | 付费会员 | 200 | 198 | 2 | 单独说明 | 对账权益 |
| C | 90-180 天读者 | 3000 | 待定 | 待定 | 暂缓发送 | 2 周后再评估 |
| D | 冷名单 | 8000 | 不导入 | 不导入 | 不发送 | 只保留备份 |
相关阅读
FAQ
Substack 的历史文章要全部搬到 beehiiv 吗？ 不必。优先搬搜索流量、付费转化和经常被引用的文章。普通旧文可以保留 Substack 原链接，再在新站写一篇迁移说明。
beehiiv 会保留 Substack 的原始订阅时间吗？ 默认导入日期可能成为订阅日期。原始 signup date 要先做成 custom field 保存；如果需要恢复成系统订阅时间，按 beehiiv 帮助页提示联系支持处理。
可以把 unsubscribed 邮箱也导入吗？ 不建议。退订、硬退信和长期 inactive 邮箱会拖累新发件人信誉。它们应该只留在备份文件里，不进入首批发送名单。
迁移后打开率掉了怎么办？ 先查 accepted/rejected、退订、投诉、发送频率和冷名单比例。不要马上改标题风格或加大发送量，先用 2-4 周稳定域名和发件人。
付费会员能不能直接让他们重新订阅？ 可以，但要明确旧权益怎么处理。最好给付费会员一个单独迁移窗口，说明是否补偿剩余周期、是否换价格，以及历史发票在哪里查。
来源与时间戳
最后核对：2026-05-22。核心依据来自 Substack Help、beehiiv Help，以及 2026 年 r/beehiiv / r/Newsletters 迁移讨论。