Should you publish your newsletter issues on your own website?
Short answer
Yes. Copy every past issue to your own domain as a real web page that looks like the issue. Link your stories to your own site, not someone else's. Treat your email platform as sending infrastructure, and cross-post elsewhere only for discovery.
I never want to log in to my email platform for anything SEO-related again. It's sending infrastructure. That's its whole job.
Everything else, the archive, the search value, the AI citations, belongs on my own domain.
Why not use the email platform's built-in web archive?
Because the value accrues to the wrong place. My blunt assessment of Beehiiv, the platform I send with: it's not good for websites. Its SEO and GEO are weak, so the website layer of my local brands needs a custom platform.
One newsletter I work with gets around 8,000 site visitors a month from the platform's built-in site. I think that's the platform capping it, and a properly built site would do much better. That's my judgment, not a measured before-and-after, and I expect it to be a long-term payoff.
Many of the publishers I talk to are on Beehiiv too, so I want a streamlined way to pull a publisher's old issues onto their own site. Bringing that back catalog in is huge for SEO and GEO.
What about Substack?
Same logic. If you're Substack-only, you're renting. It's like running your business on Instagram: you want to be on Instagram, but you don't rely on it.
"Have their own branded, their own controlled platform. And then you can just cross post to Substack ... for discoverability purposes."
Own the home base, then cross-post for reach.
What does a good archive page need?
- Automatic copying. I want every issue copied over without anyone touching it.
- It looks like the real issue. The page should match what went out, in the brand.
- An Issues section. A link called Issues in the top navigation that lists every issue, plus a block on the home page with the three or four most recent.
Should newsletter links go to your site or to other outlets?
Your site. When I launched a full website for one of my brands, we were still writing two sentences about a news story and linking out to another local outlet. That meant we were sending our readers to somebody else's website and helping their traffic. Now the "read more" link goes to our own page.
A click's a click. The difference is where it lands. On your site, you get the traffic, and you get brand legitimacy: readers see a polished site with full articles under your name, over and over, and decide you're a real brand.
The work is small once you know what you're doing. I've told operators a short article takes about 10 minutes with an AI writing prompt plus making and double-checking the image. Two or three a day is plenty, around 30 minutes.
You don't need a news section either. My categories were restaurants, real estate, podcasts, local businesses and the newsletter itself. News is optional.
Can old issues become articles?
Yes. Early on, my plan was to clip the top story out of each issue and publish it as its own article, then do that for everything. Instead of old issues sitting in an archive, each piece becomes a page that can be found on its own.
What is the website for if readers get everything by email?
This is the question people get stuck on. Newsletter and social media are the distribution. Social is key. Readers don't need your website to read your newsletter.
"It's more about AI, SEO, right? Like being cited by AI and stuff, and then generating leads that way."
Judge your website on search visibility, AI citations and leads. Pageviews from your existing readers aren't the point. Owning the audience and the archive is also a bet that you can monetize it in ways you may not even know yet.
Where should the archive live?
On the same domain as everything else. See subdomain vs. root domain.
A newsletter archive is one of the easiest forms of earned attention: you already did the work of writing it. Publishing it on a page you own is how it keeps working after the email gets opened and deleted.
Answered by TJ Larkin. From product build sessions, team and partner calls and my own notes, 2025-2026. Last updated .