Browse the documentation

Search engines and answer engines

A newsletter site is plain HTML rendered on our server, with one canonical address, a written title and description on every page, a sitemap that lists every issue and a robots file that points at it. None of that has a setting, and none of it needs your attention.

The part worth your attention is what goes into it. Titles come from your issue subjects, descriptions come from your preheaders and intros, and the archive grows every time you send. Issue Mint publishes those things well; it cannot make them interesting.

One address, and one only

Each newsletter site has exactly one canonical address, and every page says so in its head. That address is your own domain once it has verified, and your {slug}.issuemint.com address until then.

Two copies of the same archive on two hostnames would compete with each other, so Issue Mint does not allow it: once a custom domain verifies, requests to the free address are permanently redirected to the matching page on your domain rather than answered. The canonical address also respects which host your domain is set up on, so a site running on www advertises www everywhere, which apex or www goes into. Nothing about this needs doing by hand, and nothing needs undoing if you add a domain later.

The title and description on each page

Your home page is titled with your newsletter’s name, your archive with “Archive” and your name, and an issue page with its subject and your name.

Descriptions work the same way. Your home page uses your newsletter description, an issue page uses its preheader when you have written one, and otherwise the opening of your intro, trimmed to about 160 characters. There are no separate SEO fields anywhere in Issue Mint, deliberately: the subject line, the preheader and the intro are copy you are already writing for readers, and asking you to write them twice would produce a worse version of both. If a search result for one of your issues reads badly, the fix is in the composer.

The sitemap and the robots file

/sitemap.xml lists your home page, your archive and every issue you have sent, each with the date it went out. /robots.txt allows crawling and names that sitemap at your canonical address.

The sitemap is built when it is asked for, and read out of the database a row at a time, so an archive of hundreds of issues stays cheap to serve and nothing needs regenerating when you send. One sitemap holds far more issues than any newsletter will ever have. Both files always advertise your canonical address rather than ours, because a sitemap listing our subdomain would point every crawler at the wrong host.

One inconsistency worth naming rather than hiding: the robots file asks crawlers to skip /submit, while the sitemap lists that page when you have submissions turned on. The instruction is the robots file, and the submission page is a form with nothing on it worth ranking either way.

Why answer engines can read the pages

Every page on a newsletter site is complete HTML when it arrives. There is no JavaScript to run, nothing loaded after the fact, and no interaction needed to reach the words.

That matters more than it used to. A crawler, a summarising assistant or somebody else’s link preview all get the same thing a reader gets: one heading, then your intro, then your links with your commentary in reading order. Issue Mint makes no claim about how any particular assistant treats your archive, and does not publish structured data for a newsletter site, so what a machine reads is the text itself.

The archive is the part that accumulates

An issue sent by email is read once. The same issue on your archive is a page that can be found, linked to and quoted for years, and every send adds another one.

That is the whole argument for having a website at all, and it is why the archive is worth linking to from your main site, your social profiles and your email signature. A hundred issues is a hundred pages about the subject you have chosen, which is a position no single page can buy. There is more on what a hosted archive is worth, and on the craft of writing issues people cite, over on the blog.

What a newsletter site does not do

Issue Mint publishes the basics well and leaves out most of what an SEO plugin would offer. This is the list, so you can stop looking.

There are no per-page title or description overrides, no noindex control, no redirect manager, no structured data, no hreflang, and no way to add a verification meta tag or a file at the root of your site. Every page declares itself as English regardless of the language you write in. No third-party analytics tag can be installed either, so the traffic figures you have are the ones Issue Mint measures, and why the robots are excluded covers what those deliberately leave out. If one of these turns out to matter to real publishers it gets built, and none of them is missing by accident.

Questions

How do I verify my site in Google Search Console or Bing Webmaster Tools?

Use the DNS method. Both tools accept a TXT record at your domain, and your DNS is yours to edit, so nothing is in your way. The file-upload and meta-tag methods cannot work, because Issue Mint has no field for either and no way to serve a file you choose.

Can I stop a particular issue being indexed?

No. There is no per-page noindex control. An issue is either sent, and so published on your archive and in your sitemap, or it is not sent, in which case its page returns 404 and nothing can find it.

Will my newsletter compete with my main website in search results?

Only if they cover the same ground, and a newsletter archive usually does not. If you would rather the two were not on separate hostnames, add a subdomain of the site you already run as your newsletter's domain, which Issue Mint supports as readily as a whole domain.

On the product side: what the archive website gives you.

Last updated 21 August 2026.

Try it on your own list.

14 days, every feature, no card. Sending works from the moment you sign up.

Start your trial