nanoPost

The WordPress Email Authority

Write for us

nanoPost publishes work the open web and the language models cannot reproduce: primary research, hands-on testing, technical reference that is correct down to the version number. If you can write to that bar, we want to hear from you. Most pitches we receive cannot, and the guidelines below exist to save us both the time.

This is not a guest-post program in the SEO sense. If the goal is a backlink, this is the wrong publication, and the link policy below is written to make that clear before you invest the effort.

What nanoPost is

nanoPost is The WordPress Email Authority. We cover the email subsystem a WordPress operator actually has to deal with: wp_mail and the transactional flows on top of it, SMTP plugins, SMTP and ESP provider integration, email authentication (SPF, DKIM, DMARC, BIMI, ARC), deliverability diagnostics, WooCommerce and contact-form mail, logging and monitoring, and the email infrastructure that sits next door (forwarding services, DNS, the CLI tools).

The scope test is one question: does this help a WordPress operator solve an email problem, or could it? General WordPress topics outside email (security, performance, page builders, SEO), general DevOps, and marketing-email tactics are out of scope. When in doubt, narrower and deeper.

The bar

Every piece, regardless of who wrote it or how, has to clear the same gates we apply to our own work.

  • Originality. Anything a generic LLM could produce from the topic title alone is rejected on sight. A piece needs a perspective, a methodology, a specific finding, or a hands-on result. If it could be replaced by an AI Overview without loss, it cannot run.
  • Correctness. Every technical claim is verified against a primary source: provider documentation, the relevant RFC, plugin source code, or your own testing. A claim that cannot be verified is rewritten as an explicitly marked inference or cut. One confidently stated wrong fact does more damage than ten missing topics.
  • Show your work. Reference pieces state the methodology in line: what you tested, how, when, against which versions. Give the reader enough to reproduce the result. Dates and version numbers are not optional garnish; they are how the claim stays checkable.
  • Depth over length. We do not publish to a word count and we do not pad to hit one. In practice, a piece that clears the originality and correctness bars usually runs well past 1,500 words because the depth requires it. A thin 800-word explainer of a topic the models already synthesise will not make it through.
  • Voice. nanoPost speaks as a publication, not as a writer: direct, technically dense, no throat-clearing, no marketing register, no first-person anecdote. Before anything publishes it passes an AI-isms check, and the check is conservative. If a sentence reads like a model wrote it to fill space, it gets rewritten. Editing here is real, not cosmetic.

Links, plainly

Contributors get a byline and editorial credit, not a link-building opportunity.

  • At most one external link in the body, and only if the piece depends on it: a primary source, a tool the solution requires, documentation the reader needs to follow. Decorative or promotional links are removed.
  • One link in the author bio, plus standard social profiles.
  • All outbound links are subject to editorial discretion and may be set nofollow. We do not accept paid links, and we do not publish content written to place one.

What we publish

The back catalogue shows the registers and the depth we are looking for:

Before you pitch, search the site (the box at the top of every page) to confirm we have not already covered the angle. A genuinely better or more current treatment of an existing topic is still welcome; a duplicate is not.

How to pitch

Email us through the contact form with:

  • Who you are and the specific expertise or testing you bring to the topic.
  • The actual claim or finding the piece will make, not just a working title. "How Postmark’s bounce handling behaves under sustained soft bounces, tested against a live account" tells us something; "A guide to Postmark" does not.
  • One or two links to prior technical work, ideally something with primary research or hands-on detail in it.

We read every pitch and reply within a few days. If it is a fit, we will agree the angle and the scope, you draft, and the piece goes through the same review pipeline as our own: content, fact-checking against primary sources, SEO, and the AI-isms gate. Expect substantive editing. The byline is yours; the standard is the publication’s.