Connecting your site
Verand needs a connection to your site for two reasons: to read your existing pages (which is what the crawl, your scores and your opportunities are all built on), and to publish drafts back once you approve them.
There are two connection types, WordPress and git-based static sites, plus an optional plugin for WordPress sites built with a page builder.
Connecting never changes anything on your site. It verifies the credentials and checks what's reachable. Publishing is always a separate, deliberate action.
You'll find all of this at Settings → Integrations.
📸 Screenshot slot:integrations-tab.png
Settings → Integrations with both cards visible, ideally one connected and one not, so the two states are clear.
WordPress
You'll need three things:
- Your site URL:
yoursite.comis fine - Your WordPress username
- An Application Password
The Application Password is not your login password. Create one inside WordPress at Users → Profile → Application Passwords. WordPress generates a long string specifically for external tools, and you can revoke it later without touching your own login. Paste that into Verand.
If your site is behind a firewall, or a security plugin blocks the WordPress REST API, the connection check will tell you rather than failing silently later.
📸 Screenshot slot:wordpress-connect-modal.png
The WordPress connect form with the three fields filled in (blur the password).
What happens when you publish
Articles arrive in WordPress as drafts. They sit in your normal WordPress drafts list, and you publish them there when you're ready. That's the default, and it's deliberate: nothing goes live without a person putting it live.
Verand checks what your WordPress supports
On connect, Verand probes the site once: which editor it uses, whether custom fields are reachable, and whether an SEO plugin owns the meta description rather than WordPress itself. What it finds changes how the post is written, so an SEO plugin's title doesn't get quietly ignored and a page builder doesn't receive a raw block of HTML.
The Verand Connector plugin (optional)
If your WordPress pages are built with a page builder, Elementor especially, the standard WordPress API isn't enough. A page builder stores its content in its own data model, and writing to the usual post content field either does nothing visible or damages the layout.
The Verand Connector is a free WordPress plugin that solves this. Verand decides what should change; the Connector applies it inside WordPress using the page builder's own data model, so the layout survives.
Install the plugin, open its Verand page in WordPress, and copy the pairing token into Verand.
You only need this if you're on a page builder. A standard WordPress theme doesn't require it.
📸 Screenshot slot:connector-pairing.png
The pairing token field, with the plugin's Verand settings page beside it if you can fit both.
Git-based static sites
If your site lives in a GitHub repository and builds to static pages (hosted on Cloudflare, Vercel, Netlify or anywhere else), connect the repository.
The recommended route is the GitHub App. Install it, grant access to the specific repository, and pick that repo from the list in Verand. No token to manage or rotate.
Or use a fine-grained Personal Access Token if you'd rather. Scope it to only that one repository, with:
- Repository permissions → Contents: Read and write
- Pull requests: Read and write
Verand works out how your repo builds pages
On connect, Verand reads the repository once and figures out how it turns source files into pages. There are three outcomes:
- Recognised static site generator: Astro, Next.js, Hugo, Eleventy, Jekyll, Gatsby and similar. Verand writes a content file with frontmatter matching your existing articles, and your own layout wraps it at build time. This is the cleanest option: nothing about your design is stored in Verand, so your pages can't drift out of sync with your template.
- Pre-rendered HTML pages: Verand derives the page shell fresh from one of your recent articles each time it publishes, rather than storing a template that would go stale.
- Not identified: Verand publishes a plain HTML fragment at the path you set, and tells you plainly that's what it's doing rather than guessing.
It also sets the path where articles land. You can override it if Verand gets it wrong. Use {slug} where the article's slug should go.
📸 Screenshot slot:github-connected-detected.png
A connected GitHub card showing the detected site type and the article path.
What happens when you publish
Publishing opens a pull request. Verand doesn't commit to your live branch on publish. You get a PR to review, with the article and its images in the same commit, and you merge it when you're happy.
Updating a page you've already published
Publishing puts a new article on your site. A different set of actions goes back and changes a page that's already there: a title or meta description, an answer block near the top, a takeaways list, source citations, an internal link, or the year-rollover sweep that updates dated references.
Each of these is a targeted edit, not a rewrite. Verand changes the specific thing you approved and leaves the rest of the page exactly as it was. If it can't work out where the change belongs with confidence, it refuses to write rather than guessing at a plausible edit.
A note on how these reach a git repo. Publishing a new article opens a pull request. Applying one of these targeted changes commits to your default branch directly, once you've approved it in Verand, because there is no draft state to hold it in. If you'd rather every change to your repository arrive as a PR, don't use the apply actions; publish and edit in your own workflow instead.
If you haven't connected anything yet
You can still use everything else. Verand reads your site from the public web for the crawl, your scores and your opportunities, so nothing depends on a connection being in place.
To get an article out without one, open it and export: Markdown or HTML, whichever your CMS takes. Exporting your own articles works on every plan, including during a trial.
Which one do I need?
You only need the connection that matches your site. Most customers connect one and never think about it again.
If you run more than one site, each site has its own connection, and connections aren't shared across sites.