SEO for a newsletter: the archive is the content

Google can rank any page it can crawl, understand and index. For a newsletter, that means the public archive and the pages that link to it. Your job is to make issues indexable, titled by topic, and linked from hubs that match how people search.

• An archive index that lists recent and popular issues.
• One URL per issue that loads as HTML without a paywall.
• A meaningful title that matches the subject, not a date.
• Topic pages that group related issues on a theme.
• A landing page for the newsletter’s name and category.

Give every issue a clean URL and a title that names the topic. Think how your reader searches. They never search “Issue number, July”. They search “postgres connection pool timeouts” or “pricing page examples”.

1. 1

   Pick a stable path pattern

   Use /newsletter/how-to-price-enterprise, not /p/id. If your platform forces an ID, add a readable slug: /p/how-to-price-enterprise-id.

2. 2

   Write the title for the subject

   On the issue page, set the <title> to the topic, about 60 characters. Example: “SaaS pricing page patterns with examples”.

3. 3

   Lead with the answer

   Open with two lines that say what the reader will learn. Example: “How to structure /pricing for mid-market. Copyable layout and CTA.”

4. 4

   Use headings for subtopics

   Break the issue into H2 sections by problem. Example: “Price anchoring”, “Enterprise contact”, “Billing FAQ links”.

5. 5

   Link to related issues and product pages

   At the end, link to your hubs and any live guides. Example: “More on pricing, and the /pricing checklist.”

A fixed issue looks like this: title that says the job, a short summary, scannable sections, and links out to your topic pages.

The landing page ranks on the brand and the category. It is where people link when they mention the newsletter. Build it as a normal landing page, not just a subscribe wall.

• URL: /newsletter, /weekly, or your chosen name.
• Title: “The [topic] newsletter”, for example “The developer marketing newsletter”.
• H1: repeat the name in plain words. Do not cram keywords.
• Two paragraphs on who it is for and what you cover.
• Links to cornerstone issues with subject lines as anchors.
• Links to topic pages: /newsletter/pricing, /newsletter/tech-seo, /newsletter/launch.
• A light archive snippet with dates, not the full feed.
• A subscribe box that does not block the content.

When fixed, /newsletter answers “what is this” in the first sentence, shows proof with a few issues, and routes readers to topics instead of a long scroll of dates.

Topics are how search works. Build a page per recurring theme. Each page links to the best issues on that theme and gives a short summary for each. This is your internal linking system.

1. 1

   Choose themes you return to

   Examples: “Pricing”, “Technical SEO”, “Launch channels”, “PostgreSQL errors”. Start with three to five pages.

2. 2

   Use a clear URL and title

   /newsletter/pricing with title “Pricing strategy for product businesses”. Avoid vague names like “Thoughts”.

3. 3

   Write two lines on the scope

   Say what this topic covers and who it helps. Then list the best issues.

4. 4

   Summarise each linked issue

   One line that names the problem and the fix. Example: “Price anchoring on /pricing: three layouts, pros and cons.”

5. 5

   Link out to your non-newsletter pages

   If you have a full guide, link it. Example: from “Pricing”, link to /pricing-page-examples.

A fixed topic page reads like a hub, not a tag feed. Everything on it helps someone who searched that theme finish their task today.

You work within the platform’s controls. Substack, beehiiv and Ghost differ on custom domains, sitemaps and canonicals. Check what yours exposes and fill the gaps with links and clear titles. Do not assume defaults are right.

• Custom domain: use your own domain where the platform supports it. It ties the archive to your brand.
• Sitemaps: if the platform ships a sitemap, submit it in Search Console. If not, make sure your archive and hubs are linked and discoverable.
• Canonicals: where you can set them, point each issue to its own URL. Avoid a global canonical to the homepage.
• Titles and slugs: always set the subject in both, within the platform’s limits.
• Archive visibility: keep issues indexable unless they are thin or paywalled. Set paywalled pages to noindex where the platform allows it.

If a feature is missing, compensate. Use strong internal links from /newsletter and the topic hubs. Link to each new issue from a recent issue and from a hub. Assistants and crawlers follow links in HTML as of 2026.

A newsletter on a subdomain of a platform shares less with your site than one on your own domain. If you can, put the archive on your domain or a subdomain you control. Keep it in the same site family as your product pages.

• Best: yourproduct.com/newsletter and topic hubs under it.
• Good: newsletter.yourproduct.com if the platform needs a subdomain you control.
• Weak: yournews.substack.com when your site is yourproduct.com. It will still rank, but shares less with your site.

If you move later, plan redirects. Map every old issue URL to its new one. Then update links from your product site and your social profiles to the new home. Use the domain change checklist when you switch hosts or domains to keep the archive’s equity with you.

Links are your control. Use them to show what matters and to surface old issues when they fit a query. Do not leave issues as orphans that only the date feed links to.

• From the landing page, link to topic hubs and cornerstone issues.
• From each issue, link to one or two related issues and one topic hub.
• From each topic hub, link to key issues and to any deep guides on your site.
• Add a compact “Recent issues” block on high traffic pages like /pricing and /guides/getting-started where relevant.

A fixed archive has no dead ends. Every popular page points to a next click that matches intent. Example: the issue on “feature flags vs config toggles” links to the “Release engineering” topic and to your /guides/feature-flags page if you have one.

Keep it simple. Your archive should be easy to crawl and index. These checks fit any host and do not need plugins or hacks.

• HTML first: issues should render core content in HTML, not only in client JavaScript.
• Titles and meta descriptions: set unique, descriptive text. Keep titles around 60 characters and descriptions within 155 characters.
• Canonicals: each issue should canonical to itself. Topic hubs canonical to themselves.
• Pagination: if your archive paginates, make sure later pages link back to the main archive and to hubs. Do not canonical them to page 1.
• Sitemap: if you have one, make sure it lists issue URLs and hub URLs. Submit it in Search Console.
• Images: set alt text that matches the section it sits in. Compress images so the page loads fast.
• Noindex where needed: noindex thin tag pages or paywall stubs if your platform allows it.

Measure crawling and search with Search Console. Verify the property, submit the sitemap if present, and watch the Performance and Pages reports. Fix “Alternate page with proper canonical tag” where the platform points to the wrong URL. Use the URL Inspection tool when an issue is not indexed yet.

Google Discover can send bursts to publications. A clean, helpful issue can qualify when it matches a reader’s interests and recent activity. Treat it as upside, not a plan. You cannot force it.

• Write for people first, on timely or evergreen problems.
• Use clear titles and images that explain the subject.
• Keep the issue readable on mobile. Avoid intrusive overlays.
• Publish consistently so the archive looks alive.
• Link new issues from your landing page and topic hubs quickly.

When a burst lands, some readers will search the topic later. Your hubs and landing page should capture that follow-on search and route it to the right issues and product pages. A fixed setup turns spikes into lasting traffic to the archive.

Assistants pull from search-backed indexes and cite pages that answer a question directly. Your archive can be cited if issues state the problem and give the answer in plain structure. This is part of generative engine optimisation as of 2026.

• Allow the answering crawlers in robots.txt so your issues can be found by assistants. That includes Googlebot, Bingbot, OAI-SearchBot, Claude-SearchBot and PerplexityBot.
• Keep answers scannable with headings, lists and clear names for products and people.
• Get listed on roundups and comparison pages in your niche. Assistants often cite those.
• Host the archive content in HTML and keep it public. Assistants cannot cite what they cannot fetch.

To measure it, ask assistants buyer questions your issues answer. Note which pages get cited. Then tune titles and structure so a model can quote you cleanly. Add an llms.txt if you have a site policy to publish.

Treat the archive as a product. Plan issues around jobs to be done. Keep the hubs tidy. Update or merge thin pieces. Your goal is a family of pages where each one earns a search of its own.

1. 1

   Plan issues by search intent

   Match real searches in your niche. Examples: “how to set up SSO in Next.js”, “Shopify product page SEO checklist”, “Stripe webhook retries”.

2. 2

   Use Search Console to spot demand

   Watch impressions rise on topic hubs and issues. Ship follow-ons when you see queries appear that you can answer better.

3. 3

   Refresh winners

   When an issue earns search, add a short update on top. Link it from the landing page for a week to show activity.

4. 4

   Prune or merge

   If two issues target the same query, link one as the canonical guide and make the other a support piece with internal links.

5. 5

   Cross-link with your product

   Where it serves the reader, add a low-key CTA and a link to the relevant feature page or guide. Keep it helpful.

A fixed archive has fewer but stronger topic hubs over time, and each new issue fits a gap the hubs reveal. The feed is an outcome, not the structure.