MergePressGet early access

The content service that can only open pull requests.

MergePress writes SEO content for your Astro, Hugo, 11ty, Jekyll, or Next site — and proposes it as a PR. You tap Approve; your site deploys itself; revert is one click.

3 GitHub permissions · no deploy keys · no CMS logins · nothing merges without your approval

works withAstroHugo11tyJekyllNext.jsdeploys viaCloudflare PagesVercelGitHub Pages

Propose. Approve. Ship. Verify.

One loop, borrowed from how software already ships. Every piece of content moves through it — with a recorded approval as the only key that unlocks a merge.

  1. We open a pull request

    Proposed

    MergePress studies your repo — framework, voice, existing posts — and opens a PR on a mergepress/* branch: the post, images with alt text, schema, internal links. Build-verified in a sandbox before you ever see it.

    mergepress/post-winterizing-checklist

  2. You approve it — or you don’t

    Approved by you

    One tap from your inbox, or a normal PR review. Request changes and we revise. Nothing merges without a recorded approval: who approved, when, through which channel. That record is your audit trail of human oversight.

    review: approved · via email-token

  3. Your own pipeline deploys

    Merged

    The merge triggers the deploy you already have — Cloudflare Pages, Vercel, GitHub Pages. We hold zero deploy credentials. Your site ships itself, exactly like every other commit.

    merged by mergepress[bot] · Verified

  4. We confirm it’s actually live

    Live · verified

    We check the published page by its content — never just an HTTP 200 — ping IndexNow so Bing and the AI engines see it, and log the whole cycle into your monthly report. Regret it later? Revert the merge. One click.

    GET /blog/winterizing-checklist → content match ✓

Our permission screen is the pitch.

The typical AI content tool asks for your CMS admin login — WordPress passwords, Webflow tokens, full write access to your live site. MergePress asks for three GitHub permissions, and the interesting part is what they don’t include.

mergepress[bot] requests access

3 scopes, total
The three GitHub permissions MergePress requests, and why
PermissionLevel
Contents

Read your site to learn its structure and voice; create branches and commits for proposed posts.

Read & write
Pull requests

Open the PR, read your review, merge only after you approve.

Read & write
Metadata

Mandatory GitHub baseline — repo name, default branch.

Read

That’s the whole list. No org permissions, no Actions, no Secrets, no Workflows — a repo admin can install it without involving org owners.

What MergePress cannot do

Enforced by GitHub’s servers — not by our promises.

  • Cannot touch your CI or workflows

    GitHub rejects, server-side, any push to .github/workflows/ from an app without the separate Workflows permission. We never request it.

  • Cannot read secrets, settings, or deploy keys

    Those are separate permissions we don’t have. There is nothing to leak because there is nothing we can reach.

  • Cannot push to your default branch

    Our own broker refuses it, and every change arrives as a PR you can read line-by-line before anything happens.

  • Cannot deploy

    We hold no deploy credentials for any platform. Publishing only happens when your approval merges the PR.

The contrast that matters: Unlike dependency bots — which must request the Workflows permission to do their job — a content service never needs it. And unlike CMS-credential tools, MergePress can’t publish anything you didn’t approve, because the approval is the merge.

Read the full security model

Two ways to approve. One system.

For the owner who never wants to see GitHub

Approve from your inbox

Topic choices arrive by email; you tap one. The draft arrives with a private preview link; you tap Approve. That’s the entire workflow. No dashboard, no login, no new tool to learn.

  • One-tap signed approval links
  • Private preview of every post before you decide
  • Do nothing and nothing publishes — ever

For developers and agencies

It’s just a pull request

Install the GitHub App on the repos you choose. Review the PR like any other contribution — diff, checks, comments. Your review approval (or your own merge) is the authorization. Email drops to notification-only.

  • Normal PR review is the approval channel
  • Build-verified before the PR is even opened
  • Multi-repo: one install motion per client site

What ships in every PR

You approve one thing — a post worth publishing. The invisible plumbing Google actually checks rides along in the same diff.

every-post.diff+5 guarantees
1## alongside the post you approved:
2+sitemap.xml — lastmod that only changes when content does · truthful lastmod
3+Article + Organization schema, valid JSON-LD · rendered, not promised
4+internal links from your homepage and recent-posts block · the #1 fix for “Discovered — not indexed”
5+descriptive alt text on every image · accessibility and image search
6+IndexNow ping the moment the PR merges · Bing + the AI engines
7## zero extra approvals needed — it’s one diff

One rail. More playbooks.

Blog posts are the wedge. Everything else rides the same propose → approve → ship-and-verify loop — same scoped access, same audit trail, same one-tap approval.

playbook/01

Monthly proof-of-value report

Leads and calls first, then clicks, impressions, and a completed-work log with honest timeline framing (“month 2 of 6 — on track”). Not a rankings dump.

playbook/02

Content refresh & decay rescue

Search Console decline detection turns into refresh PRs. Your old posts do most of the work — updating them is the highest-yield move in content SEO.

playbook/03

Site-health fix PRs

Broken links, redirects, image weight, Core Web Vitals, orphan pages. Small, build-verified PRs so your site quietly gets better every month.

playbook/04

Google Business Profile

Posts derived from each published article, review replies drafted for your approval, hours and attributes kept in sync. Local visibility on the same rail.

playbook/05

Honest AI-visibility panel

Does ChatGPT or Perplexity mention you for the queries that matter? Screenshot-proof in your report — and no “we hack ChatGPT” claims, because nobody can.

playbook/06

Everything in your git history

Every post, fix, and config change is a commit you own. Cancel any time and keep all of it — portable to any workflow, forever.

Founding rates lock in for good

Priced per approved post. Never per dumped article.

Beta pricing for founding customers. Volume tools sell you 30 unreviewed articles a month; we sell you a handful you actually approved — with the audit trail to prove it.

Starter

$99/ month

A steady, reviewed publishing cadence with the plumbing done right.

  • 2 approved posts / month
  • SEO plumbing in every PR
  • IndexNow + sitemap on merge
  • Monthly proof-of-value report
Get early access
Recommended

Growth

$199/ month

Adds the optimization loop driven by your own Search Console data.

  • 4 approved posts / month
  • Content refresh & decay rescue
  • Site-health fix PRs
  • Everything in Starter
Get early access

Local Pro

$349/ month

The full local stack for businesses that live on Google Maps.

  • Google Business Profile posts & review replies
  • Local rank grid in your report
  • AI-visibility panel with screenshots
  • Everything in Growth
Get early access

every tier: nothing publishes without your recorded approval · cancel any time, keep everything

Fair questions

The ones developers actually ask before installing anything on a repo they’re responsible for.

What happens when I cancel?

You keep everything. Every post, image, and config file is already in your repository, in your git history. Uninstall the GitHub App and every credential dies instantly — we retain no access of any kind. There is no export step because there was never an import step.

Can you break my website?

No — and not because we’re careful, but because we’re constrained. Every change is a PR that’s build-verified in a sandbox before you see it; we can’t push to your default branch; and GitHub blocks CI and workflow access server-side because we never hold that permission. The worst case is a PR you close without merging.

Do you ever auto-publish?

Never. A merge happens only after a recorded approval — your one-tap email link, your PR review, or you merging it yourself. Silence means nothing ships.

Which platforms do you support?

Static and git-backed sites: Astro, Hugo, 11ty, Jekyll, and Next — deployed on Cloudflare Pages, Vercel, or GitHub Pages. If your site builds from a git repo, we can probably work with it; we verify your exact setup during onboarding.

Isn’t this just AI slop?

The opposite bet. Volume tools dump 30 unreviewed articles a month — the exact pattern Google’s policies now target. MergePress ships 2–4 posts that a human (you) explicitly approved, each with a recorded review in your git history. Low volume, real oversight, and an audit trail that proves it.

Your next post is a pull request away.

Early access is open for founding customers on Astro, Hugo, 11ty, Jekyll, and Next stacks. Tell us about your site — we’ll open a sample PR against a copy of it so you can see the loop before you commit.