# Bloggable

> An AI blogging platform that researches topics, writes articles in a brand’s own voice,
> optimises them for both search engines and AI answer engines, and publishes them to a blog
> it also hosts. Autopilot runs the whole loop on a schedule, with a quality gate that holds
> back any draft failing the account’s thresholds for length, answer-engine score and
> how human the writing reads.

Bloggable is a trading name of Referr Ltd, a company registered in England and Wales
(Company No. 14651607). It is the CMS and the host: it imports an existing blog once
(WordPress, Ghost, Medium, Substack, or any site with a sitemap), publishes to its own hosting on a
path, a premium handle or a custom domain, and can additionally publish each post out to a
WordPress site, a Ghost site, or a signed webhook the customer configures.

## What it does

- **Autopilot** — three levels: topic discovery only, topic discovery plus drafting, or fully
  unattended publishing. Output is configured as volume per week; cost is forecast before it runs
  and capped by a per-blog monthly credit budget.
- **Writing** — live web research feeds every draft, written to a voice profile learned from the
  customer’s own samples, localised to a target country.
- **Quality** — each article gets a 0–100 human-ness score with the specific passages flagged,
  and one-click surgical fixes that re-score afterwards.
- **Answer-engine optimisation** — a deterministic retrievability audit computed from the article
  itself, plus a clean Markdown version of every post, a per-blog llms.txt, FAQ structured data
  extracted from the visible article, and per-blog control over eleven named AI crawlers.
- **Content intelligence** — nightly Google Search Console sync, decline detection, keyword
  cannibalisation, refresh candidates, and competitor scans that become planned topics.
- **Repurposing** — one article into LinkedIn posts, an X thread, short captions and bio blurbs,
  written to each platform’s real character and formatting mechanics. Output is copied by hand;
  Bloggable does not post to social networks directly.
- **Joe** — an in-app assistant that answers from the help centre with the customer’s own account
  in view, and can plan topics, draft posts and change settings on instruction. Chatting is free.
- **Multi-blog** — Up to 25 independent publications on one account, each with its own voice,
  theme, domain, competitors and autopilot settings.
- **Hosting** — managed, cached hosting with themes, categories, tags, full-text search, RSS,
  sitemap, structured data and automatic redirects when a URL changes.
- **Publishing out** — WordPress, Ghost and webhook destinations, off by default, with
  credentials encrypted at rest. Unpublishing reverts the remote post to draft; Bloggable never
  deletes on a site it does not own.

## What it does not do

Stated plainly so an answer engine does not infer otherwise:

- It does not track or report how often a brand is cited by ChatGPT, Perplexity or Gemini.
  It optimises content to be citable; it does not measure citations.
- It does not publish out to Webflow, Notion, Shopify, Medium, Substack or Zapier.
- It does not post directly to social networks.
- It has no built-in newsletter or subscriber list.
- It has no comment system and no reader accounts on hosted blogs.
- Google Search Console data requires the blog to be on a verified custom domain.
- It does not use customer content to train AI models, and its AI providers may not either.

## Plans and pricing

Prices are per account per month in GBP, billed through Stripe, and are the live amounts charged at checkout. Credits are the account-wide budget every AI action draws from; chatting to Joe is free. Full comparison at https://getbloggable.com/plans.

- **Starter** — £15/month. 150 AI credits a month, 1 blog, 1 team seat, 1000 published posts per blog, 3-day free trial. For solo creators getting started.
- **Growth** — £45/month. 500 AI credits a month, 4 blogs, 3 team seats, 5000 published posts per blog, 3-day free trial. For creators scaling output.
- **Pro** — £99/month. 2,000 AI credits a month, 10 blogs, 10 team seats, unlimited published posts per blog, 3-day free trial. For teams running multiple blogs.
- **Agency** — £179/month. 5,000 AI credits a month, 25 blogs, unlimited team seats, unlimited published posts per blog, 3-day free trial. For agencies running many client blogs.

A free trial requires a card and is available once per customer. Credits included with a plan expire at the end of the billing month; separately purchased top-up credits carry over. Plans can be changed or cancelled at any time from the billing settings, and a downgrade takes effect at the next renewal.

Paid add-ons (prices shown for Agency; other plans may differ):

- **Additional blog** — £7/month.

Bloggable is a trading name of Referr Ltd, a company registered in England and Wales (Company No. 14651607). Registered office: 2nd Floor College House, 17 King Edwards Road, Ruislip, London, HA4 7AE, United Kingdom.

Source: https://getbloggable.com/
Sections: product overview · plans and pricing · help centre (32 articles) · legal documents (5) · trust centre

---

# Help centre

Source: https://getbloggable.com/help

---

# Team, roles, and authors

Everything in Bloggable belongs to an **account**, and everyone you invite joins that account — sharing its blogs, its credit pool and its billing.

## Roles

| Role | Can do |
| --- | --- |
| **Owner** | Everything, including billing and cancelling the plan |
| **Admin** | Settings, team, personas, archiving blogs, all content work |
| **Member** | Create and edit content, run AI actions, publish |
| **Viewer** | Read-only — can see the work and the analytics, change nothing |

Billing is owner-only. Team management and account settings are owner or admin. Permanent deletion of content is reserved for owners.

**Joe respects exactly these boundaries.** A viewer can ask Joe anything and get real answers, but Joe won't perform an action their role doesn't allow — the tools simply aren't offered to him. There's no route around the permission model through the assistant.

## Inviting people

Owners and admins invite by email from **Settings → Team**. Your plan sets how many seats you have; **Settings → Billing** shows the live number for your account.

Two known limits worth planning around:

- **Roles are account-wide.** You can't currently scope a member to a single blog.
- **A user belongs to exactly one account.** There's no account switching, so someone who works with you and with another Bloggable customer needs separate logins.

## Viewer seats and clients

Viewer is the seat to give a client or a stakeholder who wants to watch without touching. Note that ownership transfer isn't built yet — you can't hand a blog over to a client's own account, so agencies should plan to keep client blogs under their account.

## Personas — bylines without seats

A **persona** is a virtual author: a name, a bio and a photo, with no login and no seat cost. Use them to byline posts under a pen name, a brand voice, or a subject-matter expert who doesn't need access to the tool.

Personas can be scoped to the account or to a single blog, and you can have as many as you like. Autopilot can use one as its default byline — and if you don't set a byline at all, it assigns a persona rather than publishing anonymously, because an article with a named author is treated better by both search and answer engines.

Creating a persona needs admin or owner.

Source: https://getbloggable.com/help/team-and-roles

---

# Analytics

Every Bloggable blog reports its own traffic — views and approximate unique visitors, per post and per day.

## How it's measured

First-party, with no cookies and no third-party scripts. The blog records a view itself; nothing is sent to an analytics vendor, and there's no consent banner to add because there's nothing to consent to.

That design has a trade-off worth stating: visitor counts are **approximate**. There's no cross-site identity being tracked, so "unique visitors" is a good estimate rather than a precise headcount. For deciding which posts are working, that's more than enough.

## Where to find it

On the blog's **Analytics** cards. You get views and visitors over time, and per post.

## What this is not

It isn't a replacement for Google Search Console. Bloggable's own figures tell you **what happened on your blog** — which posts got read. Search Console tells you **what happened before that** — which queries you appeared for, where you ranked, how often people clicked. You want both, and the decline detection in *Content intelligence* depends on the second.

See *Google Search Console* for connecting it, and note that it needs a custom domain to collect anything.

## Asking Joe

Joe can read your blog stats — post counts, published counts, activity — so *"how's the blog doing?"* is a reasonable question to just ask him.

Source: https://getbloggable.com/help/analytics

---

# Content intelligence

**Intelligence** is the screen that tells you what to do with the posts you've already published. Most blogs fail slowly, not loudly: articles that ranked stop ranking, two posts start competing for the same query, drafts sit half-finished. Intelligence surfaces those.

It reports across your whole account, not one blog at a time.

## What it flags

**Refresh candidates** — posts that have aged out of accuracy or relevance. Refreshing rewrites the article while keeping its URL, so whatever ranking and backlinks it has earned survive the update.

**Decliners** — posts losing rank or traffic. This is the most valuable signal in the product and it needs **Google Search Console** connected to work properly; without it there's no rank data to detect a decline in. See *Google Search Console*.

**Keyword cannibalisation** — two or more of your posts competing for the same query. They split the signal and both rank worse than one good post would. Intelligence names the pair so you can merge, differentiate or redirect.

**Stale drafts** — work that was started and never finished.

**Competitor themes and counter-angles** — from the weekly competitor scan, based on the URLs set in each blog's settings. Counter-angles feed back into autopilot's topic planning, interleaved so every monitored competitor gets a hearing rather than the loudest one dominating.

## Acting on it

Every insight has a fix attached — you can rewrite a decaying post straight from the dashboard rather than finding it, opening it and deciding what to do. Joe can do the same: *"which of my posts are losing traffic?"* then *"refresh that one"*.

## Getting the most from it

- **Connect Search Console.** Half of what Intelligence does is inference until it has real query data.
- **Fill in competitor URLs** on each blog. No competitors, no competitor intelligence.
- **Give it a back catalogue.** Intelligence is about existing posts, so it has little to say in your first month. If you've imported an existing blog, it has plenty to say on day one.

## Related

- *Analytics* — first-party traffic figures, which work without any integration.
- *Google Search Console* — clicks, impressions, CTR and position.
- *Autopilot* — where competitor counter-angles end up as planned topics.

Source: https://getbloggable.com/help/content-intelligence

---

# Connecting Google Search Console

Search Console is where Google reports what your blog actually does in search: which queries you appeared for, how often, where you ranked, and how many people clicked. Connecting it turns several Bloggable features from estimates into measurements.

## Before you start: you need a custom domain

**Google only reports on a domain you can prove you own.** A blog published to a Bloggable address — `getbloggable.com/b/…` or a `.bllog.io` handle — sits on a domain you can't verify in Search Console. The connection will succeed and then collect nothing, which is a confusing failure mode, so it's worth being clear about up front.

Connect a custom domain to the blog first. See *Publishing posts and custom domains*.

## Connecting

1. **Integrations → Search** in the main nav.
2. Connect Google Search Console and authorise access.
3. Pick which Search Console property maps to which blog.

Sync runs nightly. Expect the first useful data the next day, and expect Search Console itself to lag by a couple of days — that's Google's reporting delay, not ours.

## What it unlocks

- **Clicks, impressions, CTR and average position** per post.
- **Decline detection** — posts losing rank or traffic, flagged in **Intelligence**.
- Better refresh prioritisation, because "which posts are slipping" becomes a fact rather than a guess.

## If it's connected but there's no data

In order of likelihood:

1. **The blog isn't on a custom domain.** See above. This is the common one.
2. **The wrong property is mapped.** A `domain` property and a `URL-prefix` property in Search Console are not interchangeable; make sure the one you picked covers the URLs your posts actually live at.
3. **It's too soon.** Google needs the site indexed and needs a few days of data before it reports anything.
4. **The blog isn't indexed.** Check the blog's SEO settings allow indexing, and that the posts are published.

## Disconnecting

**Integrations → Search**. Disconnecting stops the nightly sync; previously synced figures stay on your posts.

## A known gap

Search Console data is stored per post but isn't yet surfaced in the editor — there's no per-post Search Console panel while you're writing. The data is used by **Intelligence**, which is where to look for it today.

Source: https://getbloggable.com/help/search-console

---

# Autopilot

**Autopilot** runs the content loop for a blog on a schedule: it finds topics, writes them, checks them, and — if you let it — publishes them. It's configured per blog under **Autopilot**, with a six-step setup wizard that can activate several blogs in one pass.

Autopilot spends credits like any other AI generation. Everything below exists to make sure it spends them on posts you'd have wanted anyway.

## The three levels

Autopilot is one setting with three positions, and you should climb them in order.

**1. Topic discovery.** Keeps a buffer of researched, ranked topic ideas topped up. Nothing is written. You approve or reject each one, and every suggestion comes with the research that justified it, so you can see *why* it was proposed. This is the level to start on: it tells you whether Bloggable understands your niche before it spends anything on drafting.

**2. Auto-drafting.** Writes full drafts from approved topics and leaves them for you. Nothing goes public without you opening it.

**3. Full autopilot.** Sources, writes, checks, schedules and publishes unattended. It runs hourly.

Off is the fourth position, and pausing the blog also stops autopilot.

## Setting the volume

Rather than picking an abstract "level of aggression", you configure output: *five planned, three drafted, one published a week* (or per month). The pipeline sizes itself to hit that. Cadence — daily, three times a week, weekly, fortnightly, monthly — sets the rhythm.

Before you switch anything on, the wizard shows a **live credit forecast** for the volume you've asked for. You'll know the monthly cost before it starts, not after.

## The guardrails

**The publish gate.** Nothing publishes unless it passes every threshold you set: minimum word count, minimum AEO score, and the AI-integrity check. These are objective measurements, not the model's opinion of its own work. A draft that fails is held back and flagged for you, not quietly published anyway.

**A hard budget cap.** Set a monthly credit ceiling per blog and autopilot stops at it. This is separate from the forecast — the forecast is an estimate, the cap is enforced.

**Approval.** At discovery level, every topic waits for your yes or no. Nothing gets written from a topic you rejected.

**It never repeats itself.** A topic that has already been published, drafted or queued cannot be planned again — on any path. That covers autopilot, "ask AI for ideas", and Joe. You will not wake up to three articles about the same thing.

## Where topics come from

You choose which sources feed it:

- **Your own site.** Indexed pages from your website and helpdesk steer what gets planned — not just where posts link.
- **Competitors.** The blogs you listed in the blog's settings. Counter-angles found by the weekly competitor scan become next week's planned posts, interleaved so every monitored competitor gets a hearing rather than the loudest one dominating.
- **Keyword seeds.** Terms you supply directly.
- **Cluster mode** organises output around pillar topics instead of scattered one-offs.

You can also give a **briefing** — free text that constrains everything it plans, e.g. "no listicles, and never write about pricing".

## Optional stages

Each adds credits per post, so each is a toggle:

- **Featured image** — picks and attaches an image automatically.
- **Humanise** — rewrites the draft to strip AI patterns and apply your voice.
- **AI-pattern check** — scores how machine-written the draft reads, and flags anything below your threshold for human review.

## Publishing settings

Set the publish time and timezone, default tags, the target funnel mix (top / middle / bottom of funnel) and the default byline. The byline can be a team member or a persona; if you don't set one, a persona is assigned automatically so posts aren't published anonymously.

## Running on demand

**Run now** triggers a manual pass. It's rate-limited to roughly once an hour per blog, which keeps a stuck loop from becoming an expensive one.

## Watching it

The **activity log** records every run: what ran, what it produced, what it cost, and why anything was held back. If autopilot fails repeatedly, we email you.

> **A note on the per-event notification toggles.** The wizard offers switches for "planned topic added", "draft ready" and "published". These are not yet wired up — failure emails do send, but those three per-event notifications currently do nothing. Don't rely on them.

## A sensible rollout

1. Run at **discovery** for a couple of weeks. Approve and reject honestly.
2. Move to **auto-drafting**. Read the drafts. Adjust the briefing and voice based on what's wrong with them.
3. Only then go to **full autopilot**, with the quality gate set where you'd actually be comfortable, and a budget cap you'd be happy to pay.

Source: https://getbloggable.com/help/autopilot

---

# Planning topics and the content calendar

Before anything gets written, it gets planned. The **content calendar** is where planned posts live, and every post moves through the same states:

**idea → planned → scheduled → drafting → generated → published**

You can see and act on this pipeline whether the topics came from you, from autopilot, or from Joe.

## Where topics come from

- **Ask for ideas.** Have the AI plan a batch against your blog's niche, audience and competitors.
- **Autopilot's topic discovery.** Keeps a buffer of researched, ranked ideas topped up automatically. See *Autopilot*.
- **Joe.** *"Give me five post ideas about X"*, and he'll add the good ones to the calendar on request.
- **You.** Add a topic directly.

## Why this topic

Suggested topics come with the research that justified them — the gap, the query, the competitor angle. It's there so you can reject the ones based on reasoning you disagree with, rather than judging a bare title.

## Approving and rejecting

Planned topics wait for a yes or no. Rejecting is not a wasted step: it's the cheapest possible correction, because a rejected topic is one you didn't pay to have written.

## It won't suggest the same thing twice

A topic already published, drafted or queued cannot be planned again — on any path. Autopilot, "ask for ideas" and Joe all check against the same history. You won't end up with three articles on one subject because three different routes suggested it.

## Cluster mode

Autopilot can plan around **pillar topics** rather than scattered one-offs, building a cluster of related articles that link to each other. This is usually a better use of the same number of posts, particularly on a young blog.

## Funnel balance

You can set the target mix across top-, middle- and bottom-of-funnel posts. It stops a blog drifting into either all-introductory explainers that never sell anything, or all-sales posts nobody reads. It also pairs with **reusable elements**, where a bottom-funnel CTA can be set to appear only on bottom-funnel posts.

Source: https://getbloggable.com/help/planning-topics

---

# Creating and configuring blogs

A **blog** is a publication under your account. One account can run several — how many depends on your plan, and you can buy capacity for one more blog as an add-on rather than jumping a whole tier. Each blog is fully independent: its own voice, theme, domain, SEO settings, autopilot configuration and posts.

## Create a blog

**Blogs → New blog**. Two routes in:

- **From your website's URL.** Bloggable reads the site and infers your branding, niche and audience. Fastest start, and usually more accurate than describing yourself from scratch.
- **From scratch.** Fill in the fields yourself.

Either way you'll set:

- **Name** — what readers see.
- **Slug** — the address, e.g. `getbloggable.com/b/<slug>`. Slugs are **globally unique across all of Bloggable**, not just your account, so a common word may already be taken. You'll be told before you save.
- **Niche** and **target audience** — the two fields that most affect output quality. Every topic suggestion, every draft, every internal link decision is made against them. "Marketing" produces generic articles; "B2B SaaS pricing pages for seed-stage founders" produces specific ones.

## Renaming a blog

You can change the slug later. Bloggable keeps the old one and permanently redirects it to the new address, so published URLs, backlinks and indexed pages keep working. Retired premium `.bllog.io` handles behave differently — they are retired for good and can't be claimed again by anyone, including you, because a cross-origin redirect that a browser caches forever must never be able to point at a stranger's blog.

## The settings that matter

| Setting | Why it matters |
| --- | --- |
| **Brand voice** | Writing samples become a voice profile applied to every draft. Free to generate. See *Brand voice*. |
| **Competitor URLs** | Feeds competitor monitoring and topic research — it's how Bloggable finds angles your competitors have missed. |
| **Target countries** | Steers spelling, currency, units, examples and regulatory context. |
| **Theme** | The look of the public blog. See *Themes and appearance*. |
| **SEO defaults** | Site-level meta, canonical base, indexing and AI-crawler policy. See *SEO and answer-engine optimisation*. |
| **Custom domain** | Serve the blog from your own domain. See *Publishing posts and custom domains*. |
| **Autopilot** | Hands-off generation, configured per blog. See *Autopilot*. |

Most per-blog display toggles — table of contents, share button, "Ask AI about this article", showing the description — are **on by default**. Turn off what you don't want.

## Working across several blogs

- The **blog switcher** moves you between publications.
- **Posts** has an all-blogs view, so you can see and act on everything at once.
- **Intelligence** reports across the whole account, not one blog at a time.
- **Credits are pooled** — every blog draws from one balance.

## Pausing, archiving and deleting

- **Paused** stops autopilot but leaves the public blog live.
- **Archived** removes the blog from your active list. Reversible.
- Permanent deletion of content is reserved for owners.

## Limits

Blog count, team seats, storage and your monthly credit allowance all come from your plan, and the live numbers for *your* account are shown in **Settings → Billing** rather than being fixed here — plans change. If you need one more blog than your tier allows, the capacity add-on is usually cheaper than upgrading.

Source: https://getbloggable.com/help/creating-blogs

---

# Brand voice

The single biggest difference between a Bloggable draft you'd publish and one you'd delete is whether the blog has a voice profile. It takes five minutes and costs nothing.

## Setting it up

In the blog's settings, paste **one to five samples** of writing you want to sound like. Bloggable analyses them and extracts a voice profile — sentence rhythm, vocabulary, how formal you are, how you open and close, what you never say.

That profile is then applied to every draft, every rewrite, every humanise pass and every autopilot run for that blog.

**Extracting a voice profile is free.** It doesn't cost credits, and you can redo it whenever your writing changes.

## What to paste

- **Your own writing, if you have any.** Old blog posts, a good email, a conference talk transcript. It doesn't have to be polished.
- **Writing you admire**, if you don't. Be honest with yourself that you're borrowing a voice rather than describing one.
- **Enough of it.** Two paragraphs isn't a voice, it's a sample size problem. A few hundred words per sample is a reasonable floor.
- **Consistent samples.** Five pieces in five different registers average out into nothing in particular.

## What it doesn't fix

A voice profile controls *how* something is said. It can't supply what you know. If drafts read as fluent but empty, the problem is usually the niche and audience fields, or a topic too broad to say anything specific about — not the voice.

## Voice per blog

Voice is set per blog, not per account. If you run a technical blog and a consumer one from the same account, they get different profiles, which is the point of them being separate blogs.

## Related

- **Brand memory** — things you tell Joe to remember about your business also feed generation. See *Meet Joe*.
- **Target countries** — spelling, currency and examples adapt per blog. See *Creating and configuring blogs*.
- **Humanise** — strips AI patterns and re-applies this voice. See *Writing posts with AI*.

Source: https://getbloggable.com/help/brand-voice

---

# Themes and appearance

Your public blog is rendered by one of four themes. Pick one per blog; you can change it later without touching your posts.

| Theme | Character |
| --- | --- |
| **Minimal** | Text-first. Nothing between the reader and the writing. |
| **Cards** | Grid of post cards on the index. Visual, good with strong featured images. |
| **Hybrid** | A featured lead post plus a card grid beneath it. |
| **Editorial** | Magazine-styled, denser typography. |

## Customising

Per blog you can set:

- **Logo** and how the identity displays — logo only, name only, or both
- **Colour**
- **Navigation** links
- **Social links**
- Whether the blog description shows on the homepage

## Reader-facing toggles

These are per blog and **on by default** — turn off what you don't want:

- **Table of contents** in the post sidebar, sticky, with scroll tracking
- **Share button**
- **"Ask AI about this article"** — opens the post in ChatGPT, Claude, Perplexity or Kagi
- Reading progress bar and reading-time estimate

Readers also get full-text search across the blog, category and tag archives, and related posts, without any configuration.

## Removing Bloggable branding

The white-label add-on removes our branding from the public blog — both the footer badge and the page title. See *Plans, upgrades and top-ups*.

## Newsletter

There's no built-in newsletter or subscriber list. You can add a **subscribe link** pointing at your existing email provider, and readers go there. See *Importing an existing blog* if you're moving from a platform where your list currently lives.

Source: https://getbloggable.com/help/themes-and-appearance

---

# How AI credits work

**Credits** are what AI work costs. Your plan includes a monthly allowance; each AI action deducts from it.

Chatting with Joe is free. So is manual editing, reading things back, and extracting a brand voice.

## The essentials

- **Credits are pooled per account.** One balance, shared by every blog and every team member. Not per-seat, not per-blog.
- **Your allowance refills each billing cycle.** Higher plans include more.
- **Each action has a price.** A full research-and-write costs many times what a short inline edit does, because it does many times as much. The exact cost varies by plan, and the interface always shows it before you commit — you can't start a run you can't afford.
- **Failures are refunded automatically.** If a generation fails, you don't pay for it. This is enforced in the billing layer, not left to goodwill.
- **Voice extraction is free.**

## Roughly what things cost, relative to each other

You'll see exact figures in the app; this is the shape of it:

- **Cheapest** — an inline edit at your cursor, a repurpose destination, an AI-pattern check.
- **Middling** — SEO generation, link suggestions, a competitor analysis, a topic-discovery run.
- **More** — live web research, a draft, a refresh, humanising, an AI-generated cover image.
- **Most** — the full pipeline, which is research plus draft plus SEO plus links, and priced accordingly.

## Running low

If an action needs more credits than you have, it won't start. You'll get a single prompt showing your balance with two ways out: **buy a top-up** or **upgrade**. Nothing runs halfway and leaves you with a broken post.

We email you before you run out, not after.

Check your live balance and this cycle's usage in **Settings → Billing**, in the sidebar meter, or by asking Joe.

## Allowance versus top-ups

Two buckets:

- **Monthly allowance** — resets each cycle. Use it or lose it.
- **Top-ups** — bought separately, and they persist across cycles rather than resetting.

The usage meter shows *used out of total*, where total accounts for both. When it says you've used 80% of your total, that's the moment to decide between a top-up and an upgrade.

## Keeping the bill predictable

- **Autopilot has a hard budget cap** per blog — a monthly credit ceiling it will not cross. Set it. The forecast shown during setup is an estimate; the cap is enforced.
- **The setup wizard forecasts the monthly cost** of the volume you're asking for, before you switch it on.
- **Joe shows the total before a batch** and waits for you to confirm.

> Joe can read your balance and estimate costs, but never makes purchases. Buying credits and changing plans is always something you do yourself, and he never sees card details.

Source: https://getbloggable.com/help/ai-credits

---

# Plans, upgrades, and top-ups

Billing sits on the **account** and is shared by everyone on it. Compare tiers on **Plans**; manage your own on **Settings → Billing**.

## What a plan sets

- Your **monthly credit allowance**
- How many **blogs** and **team seats** you get
- **Storage** for uploaded media
- Which **features** are unlocked — custom domains, content sources, white-label, and so on
- The **rate you pay for top-up credits** (cheaper per credit on higher tiers)

Tiers run **Starter → Growth → Pro → Agency**. Prices, allowances and limits are live on the **Plans** page and on **Settings → Billing** for your own account — those are the authoritative numbers, and they're not repeated here so this article can't go stale on you.

## Add-ons

Some things are bought separately rather than by moving tier — an extra blog, autopilot capacity, white-label. When you only need one more of something, an add-on is usually cheaper than the next tier up. Add-on prices vary by plan.

## Upgrading, downgrading and top-ups

- **Upgrade** at any time to raise your allowance and limits.
- **Top-ups** buy one-off credits without changing your plan. Unlike the monthly allowance, top-up credits carry across billing cycles.
- **Downgrading** reduces your limits at the next cycle. It won't tombstone your blog addresses — a downgrade never costs you a URL.

## Payments

Stripe handles everything. Cards, invoices, receipts and cancellation are all in the billing portal, reachable from **Settings → Billing**. Bloggable never stores your card details, and neither Joe nor our support team can see them.

We can sell in several currencies. Which ones are available depends on the plan — a currency is only offered where a real price exists for it, so what you see quoted is what you'll be charged.

## Trials, cancellation and account lock

Accounts start on a trial. When a trial ends without a plan, or a subscription lapses, the account **locks**: the app pauses and you're sent to **Plans** to reactivate. Your content is not deleted — it's waiting for you.

While locked:

- Joe stays available, read-only.
- **You can still reach a human.** Escalation to support is deliberately kept open on a locked account, because billing trouble is the most likely reason you'd need one.

Cancelling is done through the Stripe portal and takes effect at the end of the period you've paid for.

## If billing looks wrong

If your credits didn't reset when they should have, or your plan shows the wrong state after a payment, tell support rather than working around it — those are usually fixable in minutes at our end. See *Getting support*.

Source: https://getbloggable.com/help/plans-and-billing

---

# Getting started with Bloggable

Bloggable is an AI blogging platform. You create one or more blogs, generate and edit posts with AI, and publish them to a blog we host — either at a Bloggable address or on your own domain.

It is the CMS *and* the host. Bloggable doesn't publish out into WordPress or Ghost; it replaces them. If you already have a blog elsewhere, you bring it across once (see *Importing an existing blog*) and publish from Bloggable afterwards.

## Your first 20 minutes

1. **Create a blog.** **Blogs → New blog**. Give it a name, a niche and a target audience. These aren't decoration — every topic suggestion and every draft is written against them, so a vague niche produces vague articles. If you already have a website, you can create the blog from its URL and Bloggable will infer the branding, niche and audience for you.
2. **Set your brand voice.** Paste one to five samples of writing you want to sound like into the blog's settings. Bloggable extracts a voice profile and applies it to everything it writes. This step costs no credits. See *Brand voice*.
3. **Write your first post.** Open **Posts → New post** and either give the AI a topic, or run the full pipeline (research → draft → SEO → internal links) in one pass. See *Writing posts with AI*.
4. **Review it properly.** Read the draft. Check the content score panel, fix anything flagged, and edit the parts only you could have written — the specifics, the opinion, the first-hand detail.
5. **Publish.** Publish now, or schedule it. See *Publishing posts and custom domains*.
6. **Then consider Autopilot.** Once you know what a good Bloggable post looks like for your blog, switch on Autopilot to keep producing them on a schedule. Doing this before step 4 is the most common way to end up with content you don't like at volume.

## The onboarding checklist

New accounts get a checklist in the top bar that tracks the setup that actually affects output quality — voice profile, niche and audience, competitor URLs, a first published post, and so on. Each item deep-links to the exact field it's asking about. It's derived live from your account, so it stays honest: ticking things off means the setting really is set.

## Where things live

| Section | What it's for |
| --- | --- |
| **Dashboard** | Account overview, recent activity, credit balance |
| **Blogs** | Create and configure blogs — voice, theme, SEO, domain, competitors |
| **Posts** | Every post across every blog, and the editor |
| **Autopilot** | Hands-off content generation on a schedule, per blog |
| **Intelligence** | Which existing posts need attention, and why |
| **Settings** | Account, profile, integrations, team, billing |

## Two things worth knowing early

- **Credits are pooled per account**, not per blog or per person. Everything your team generates comes out of one balance. See *How AI credits work*.
- **Joe is free to talk to.** The orb in the bottom-right of every signed-in page answers product questions, reads your account, and can carry out real work on request. Asking him questions costs nothing. See *Meet Joe*.

Source: https://getbloggable.com/help/getting-started

---

# Meet Joe, your AI copilot

**Joe** is the assistant on every signed-in page — the orb in the bottom-right corner. He isn't a chatbot bolted onto a help centre: he can read your account and carry out real work in it.

**Talking to Joe is free.** Chat, questions, lookups and reading things back to you cost no credits. Only work that calls the content AI — writing, researching, SEO, repurposing — costs credits, at exactly the same price as doing it yourself from the interface.

## What Joe can do

**Answer questions about the product.** He searches these help articles directly, so anything documented here is something he can answer — usually with a link to the full article.

**Answer questions about your account.** Which blogs you have, how many posts are published, your credit balance and this cycle's usage, what's in the pipeline.

**Do the work.** Plan topics, research, write a post, run SEO, suggest internal and external links, refresh an ageing article, repurpose a post for social, publish or unpublish, create a blog, change blog settings, save and place reusable elements.

**Work inside the editor.** With a post open, Joe acts on *that* post: write it, improve it, redraft it from your written feedback, fix a specific flagged issue, rewrite a selection, set the title.

**Remember things.** Tell him something about your business and he keeps it; it then feeds future drafts. Ask him to forget it and he will.

**Get you a human.** If he can't help, he can escalate to support and hand over the conversation as context.

## What Joe won't do

- **He never touches payments.** He can tell you your balance and estimate what something will cost, but buying credits or changing your plan is always something you do yourself. He never sees card details.
- **He mirrors your role exactly.** A viewer can ask him anything but can't get him to change anything. Account-level actions — creating a persona, archiving a blog — need admin or owner, the same as they do in the interface. See *Team, roles and authors*.
- **He asks before spending on batches.** For a multi-post job he shows the total cost and waits for a yes.
- **He can't act on a locked account.** If a plan has lapsed he stays available and read-only. Escalating to a human stays open, deliberately — a billing problem is exactly when you need to reach someone.

## Good things to ask

- "How do credits work?"
- "How many posts are published on my blog?"
- "Give me five post ideas for my niche."
- "Write a post about *X*, then run SEO on it."
- "Which of my posts are losing traffic?"
- "Repurpose my latest post for LinkedIn."
- "What did you write for LinkedIn?" — free; he reads it back rather than regenerating.
- "Remember that we don't sell to enterprise."

If a question needs an answer we haven't documented, Joe will say so rather than invent one — and that's worth telling us about. Joe and this help centre read from the same source, so anything added here he can answer immediately.

Source: https://getbloggable.com/help/meet-joe

---

# Importing an existing blog

If you already publish somewhere else, bring it across once and publish from Bloggable afterwards. Bloggable is the host as well as the writing tool — it doesn't push posts out to WordPress or Ghost, it replaces them.

## Two ways in

**From your live site.** Paste your blog's URL and Bloggable reads its sitemap to find posts, then fetches each one. This is the easier path and the one to use whenever the old site is still online — it works on WordPress, Ghost, Medium and Substack with no export file at all.

**Upload an export.** Use this when the old site is already down, is behind a login, or you'd rather work from files you already have. Drop in:

- **Markdown** — `.md` files, with or without frontmatter, one per post
- **A zip** — a folder of markdown or HTML with its images alongside
- **WordPress** — the `.xml` file from *Tools → Export*
- **Ghost** — the `.json` file from *Settings → Migration → Export*

You don't have to say which is which; the format is detected from the file. A single WordPress or Ghost export holds your whole site, so one file can become hundreds of drafts.

Uploaded files are read in your browser, so a large site export never has to be uploaded whole.

## How it works

1. Open the blog you want to import **into**, and start the import.
2. **Discovery** scans the source — up to 100 posts in a pass — or reads your uploaded files.
3. **Choose what to bring.** You don't have to take everything, and usually shouldn't.
4. **Run the import.** Posts come across as markdown, and images are re-hosted on Bloggable rather than left hot-linking to a site you may switch off.

Import is included on paid plans. Scanning a live site finds up to 100 posts in a pass; an uploaded export can bring in up to 500 at a time. Either way it's capped at 25 re-hosted images per post — anything beyond that keeps its original image URL.

If an export holds more than the limit, import what's listed and then upload the same file again: the posts you already have are recognised and skipped, so the second run picks up where the first stopped.

## What gets brought across

Title, body, publish date, tags, excerpt and the featured image. Posts always arrive as **drafts**, whatever status they had on the old site — including posts that were published there.

Where the source records the original URL, it's kept as the post's canonical. That's also how re-running an import knows to skip what you already have, so it's safe to import twice.

## What doesn't come across

Comments, subscribers and email lists. Bloggable doesn't have a built-in newsletter — you can link out to your existing provider from the blog, but subscriber data stays where it is.

From a WordPress export, **pages** and anything in the trash are skipped — only posts are imported. From a Ghost export, pages are skipped for the same reason.

## Images

Images hosted on the old site are downloaded and re-hosted on Bloggable automatically. Images that were *inside* an uploaded zip are uploaded too, and count towards your storage the same as anything you upload by hand.

If a post points at an image that isn't in the upload, the import tells you before you commit — the post still imports, that one image just stays as it was.

## Duplicates

A post is treated as already imported when its original URL matches one you've brought in before, or — for files with no original URL recorded — when its slug matches an existing post. Those rows are ticked off and skipped by default. If you *want* a second copy, there's an option on the select screen to import them again as new drafts.

## After importing

- **Check the slugs.** Your URLs may differ from the source site's. If you're pointing the old domain at Bloggable, matching the paths matters.
- **Set your brand voice** using imported posts as the samples — you have a body of your own writing right there. See *Brand voice*.
- **Run internal link suggestions.** Imported posts don't know about each other yet.
- **Look at Intelligence.** With a back catalogue in place, it can immediately tell you which posts are worth refreshing. See *Content intelligence*.

## Moving the domain

Import the content first and check it looks right, *then* repoint DNS. Doing it the other way round means a window where your domain serves an empty blog. See *Publishing posts and custom domains*.

Source: https://getbloggable.com/help/importing-an-existing-blog

---

# Connecting your own analytics

Bloggable counts views and visitors for every blog on its own, with no cookies and nothing for you to set up. This article is about the other thing: putting **your own** analytics tag on a blog, so it appears in the dashboard your team already reports from.

The two don't compete. Adding your own tag doesn't switch Bloggable's built-in numbers off, and the two will never quite agree — see [Analytics — views and visitors](/help/analytics) for why that's normal.

## Which one should you use?

| | Cookies | Consent banner needed? | Good for |
|---|---|---|---|
| **Google Analytics 4** | Yes | Yes, in the UK and EU | Reporting alongside Ads, existing GA workflows |
| **Plausible** | No | No | A simple dashboard, privacy-first sites |
| **Fathom** | No | No | The same, on a single screen |

If your marketing team already lives in GA, use GA4. If you're starting fresh and don't want to run a cookie banner, Plausible and Fathom are both cookieless and neither needs one.

## Where to set it up

Analytics is set **per blog**, because each blog is a separate site with its own address and its own property.

Two routes to the same screen:

- **Blog settings → Analytics** — for one blog you're already working on.
- **Integrations → Analytics** (main nav) — for the account view, with every blog in one list.

Each provider is its own row. Pressing **Connect** opens the same form either way, so use whichever you're nearest.

## Google Analytics 4

1. In Google Analytics, open **Admin → Data streams** and select the web stream for this site (or create one, using your blog's public address).
2. Copy the **Measurement ID** at the top right. It starts with `G-` followed by letters and numbers.
3. In Bloggable, pick **Google Analytics 4**, paste the ID, and press **Save analytics**.

Bloggable loads `gtag.js` and sends a page view on every public page of that blog.

**You will need a cookie consent banner.** GA4 sets cookies, which in the UK and EU means you need consent before it loads. Bloggable doesn't ship a consent banner, so this is yours to add — or pick Plausible or Fathom instead, which don't need one.

## Plausible

1. In Plausible, add the site if you haven't already. The **domain** you enter there is the identifier.
2. In Bloggable, pick **Plausible** and enter that same domain — no `https://`, no trailing slash, no `www.`
3. Save.

**Self-hosting Plausible?** Fill in the optional **Self-hosted script address** with your instance's origin, e.g. `https://stats.example.com`. It must be `https` — a plain `http` address would make the whole page mixed-content and browsers would block the script anyway.

## Fathom

1. In Fathom, open **Settings → Sites** and find the site.
2. Copy the **Site ID** — the short block of capital letters in the tracking snippet, usually eight characters.
3. In Bloggable, pick **Fathom**, paste the Site ID, and save.

## Respect Do Not Track

An optional switch under the ID field. With it on, the tag isn't loaded at all for visitors whose browser sends a Do Not Track header — not loaded and then told to stay quiet, genuinely not loaded.

It's off by default because DNT is sent by a small and unrepresentative slice of browsers, and turning it on means those visits are missing from your numbers entirely. Turn it on if you'd rather honour the signal than count the visit.

## What gets tracked, and what doesn't

**Tracked:** every public page of that blog — the homepage, each post, category and tag archives, and the search page.

**Not tracked:**

- The Bloggable app itself. Your own admin sessions never touch your analytics.
- Previews rendered inside the dashboard. The blog homepage preview and the theme previews load your blog in an iframe, and the tag deliberately skips embedded loads — otherwise clicking around your own settings would inflate your traffic.
- Anything, if you've switched the integration off or cleared the provider.

## Turning it off

Pick **None** in the provider list and save. The tag stops loading on the next page view. Your historical data stays with Google, Plausible or Fathom — Bloggable never had it.

## Troubleshooting

**"I saved it but nothing shows up."** Open your blog's public address in a private window and check the realtime view in your analytics tool. Give it a minute — GA4's realtime report can lag.

**Still nothing.** Check the ID itself. A Measurement ID (`G-…`) is not the same as a Tag ID or a Property ID, and pasting a Google Tag Manager container (`GTM-…`) won't work — Bloggable loads GA4 directly, not through Tag Manager.

**"It works on the homepage but not on posts."** That shouldn't happen — the tag is loaded once for the whole blog. If you're seeing it, [get in touch](/help/getting-support) with the blog address.

**An ad blocker.** Blockers stop GA4, Plausible and Fathom for a meaningful share of visitors. This is the main reason a third-party tool reports fewer views than Bloggable's own count, which is measured server-side and isn't blocked.

Source: https://getbloggable.com/help/connect-web-analytics

---

# Instant indexing (IndexNow)

Normally a search engine finds a new post whenever it next crawls your site — which might be hours, might be weeks. IndexNow flips that around: the moment you publish, Bloggable tells the engines the URL exists.

One submission reaches every participating engine, including **Bing**, **Yandex**, **Seznam** and **Naver**.

**Google doesn't use IndexNow.** For Google, connect [Search Console](/help/search-console) — that's the equivalent there, and the two are complementary rather than alternatives.

## Switching it on

Set per blog, in the same place as analytics:

- **Blog settings → Indexing**, or
- **Integrations → Indexing** (main nav)

Flip **Instant indexing (IndexNow)** on. That's the whole setup — there's no account to create, no API key to fetch and nothing to paste.

Behind the scenes Bloggable generates a verification key and starts serving it from your blog's own address. You'll see the key and its address on the card once it's on.

## What happens from then on

- **You publish a post** → that post's URL and your blog's homepage are submitted.
- **You update a published post** → submitted again, so the engines re-read it.
- **You unpublish a post** → submitted as well. Telling an engine to re-crawl a URL that now returns "not found" is the fastest way to get it dropped from the index.

Scheduled posts are submitted when they actually go live, not when you schedule them.

## Submitting the posts you already have

Switching IndexNow on only affects what you publish from then on. To submit your existing archive, press **Submit all published posts** on the same card.

That sends your homepage plus every published post, newest first. You can do it once an hour — the engines rate-limit sites that resubmit their whole archive repeatedly, and that limit is applied to your site's reputation, not ours.

You shouldn't need it more than once. The automatic per-publish submission is the normal path.

## Does this need a custom domain?

No. Unlike Search Console, IndexNow works on a Bloggable address too.

The reason is how ownership is proved. IndexNow asks for a key file served from the site being submitted, and it treats that file as vouching for URLs at or below its own folder. For a blog on your own domain the key sits at the root. For a blog at `getbloggable.com/b/your-blog`, the key sits inside `/b/your-blog/` — so it vouches for your posts and nothing else on the shared domain.

The one case that can't work: a blog set to **redirect** to your own site rather than serve its own pages. There's nowhere for us to put a key file on a site we don't host. Submit from that site instead, and Bloggable will tell you so rather than failing quietly.

## Reading the result

The card shows the last submission — when it ran, how many URLs were accepted, and any error.

- **"URLs accepted"** — the engines took the list. It doesn't promise indexing; nothing does. It means the URL is now queued rather than waiting to be discovered.
- **"IndexNow could not verify the key file"** — the key file isn't reachable. Most often this is a blog whose address changed recently, or one whose custom domain isn't resolving. Open the key address shown on the card; it should return the key as plain text.
- **"The submitted URLs don't match the verified key location"** — the blog's address changed after the last submission. Publishing anything will re-submit against the new address and clear it.
- **"Too many submissions"** — the hourly manual limit, or the engines' own. Wait and try again; automatic submissions carry on regardless.

## Regenerating the key

There's a **Regenerate key** button. You almost certainly don't need it — the key is public by design, it proves control of the site precisely by being served from it, and there's nothing to leak.

It's there for the rare case of a submission failing verification against a stale key. Be aware that regenerating retires the old key file **immediately**, so any submission still being verified against it will fail.

## Turning it off

Flip the switch off. The key file stops resolving and nothing further is submitted. URLs already indexed stay indexed — IndexNow is a notification, not a permission.

Source: https://getbloggable.com/help/instant-indexing

---

# Connecting Slack

Post a message into a Slack channel when something happens on your blog — a post goes live, autopilot finishes a batch of drafts, credits run low.

Setup is one URL. Bloggable uses Slack's **incoming webhooks**, so there's no app to install into your workspace and no permissions review to get through.

## Step 1 — create an incoming webhook in Slack

You need permission to add apps to the workspace. If you don't have it, ask whoever does — this is the only step that needs it.

1. Go to **[api.slack.com/apps](https://api.slack.com/apps)** and click **Create New App → From scratch**.
2. Name it (Bloggable is a reasonable choice) and pick your workspace.
3. In the sidebar, open **Incoming Webhooks** and turn the toggle **On**.
4. Click **Add New Webhook to Workspace** at the bottom, choose the channel the messages should land in, and **Allow**.
5. Copy the **Webhook URL**. It starts `https://hooks.slack.com/services/`.

That URL is tied to the one channel you picked. To post into a second channel, add a second webhook and a second Bloggable endpoint.

## Step 2 — add it to Bloggable

1. **Integrations → Webhooks** in the main nav.
2. Press **Connect** on the **Slack** row.
3. Paste the webhook URL.
4. Give it a name — the channel is a good one, e.g. `#content`. Optional; we'll default it to "Slack".
5. Tick the events you want (see below).
6. **Connect**.

Then press **Test** on the new row. A sample message should appear in the channel within a second or two.

## Step 3 — choose the events

| Event | When it fires |
|---|---|
| **Post published** | A post goes live. On by default. |
| **Post updated** | A live post is re-published after an edit. Not the same as autosave — this is you pressing Update. |
| **Post unpublished** | A live post is taken down. |
| **Post scheduled** | A post is queued for a future time. |
| **Drafts ready for review** | An autopilot run produced drafts waiting for approval. On by default. |
| **Topics planned** | Autopilot added topics to the calendar. |
| **Autopilot run failed** | A scheduled run couldn't complete. On by default. |
| **Credit balance low** | The account balance dropped below the warning threshold. On by default. |

You can change these any time from the endpoint's row.

**Autopilot events report a run, not a post.** One run drafts several posts and sends one message — "Autopilot wrote 3 new drafts" — rather than three near-identical notifications.

## Account-wide or one blog?

Where you add the endpoint decides what it hears:

- **Integrations → Webhooks** (main nav) — the endpoint covers **every blog** on the account, including blogs you create later.
- **A blog's own settings → Notifications for this blog** — the endpoint covers **only that blog**.

On a blog's settings page, account-wide endpoints are listed too, marked **All blogs** and read-only. That's deliberate: without it you'd look at one blog, see nothing connected, and add a second Slack endpoint that duplicates every message.

## Slack notifications and email notifications are separate

Muting autopilot emails does **not** mute Slack, and vice versa. They're different channels with different audiences — "stop emailing me about routine activity" is a statement about your inbox, not about the channel your team watches.

Email preferences live in **Settings → Notifications**. Slack events live on the endpoint.

## Troubleshooting

**"That is not a Slack incoming-webhook URL."** Bloggable only accepts URLs on `hooks.slack.com`. A Slack channel link, a workflow URL or a bot token won't work. Re-copy it from the Incoming Webhooks page.

**The test fails with 404.** The webhook was deleted or the app was removed from the workspace. Create a new webhook and add it again — a webhook URL can't be edited in place, for the same reason a password can't.

**"Stopped after 20 failures."** The endpoint failed twenty deliveries in a row and Bloggable stopped trying. Fix the URL, then flip the row's switch off and on again — re-enabling resets the counter and starts retrying.

**Messages arrive in the wrong channel.** The channel is baked into the webhook URL, not chosen in Bloggable. Create a new webhook against the right channel and swap the endpoint.

## Removing it

Delete the endpoint's row in Bloggable and messages stop immediately. To revoke it properly, also delete the webhook in Slack — anyone holding that URL can post into the channel, which is why Bloggable encrypts it and never shows it back to you.

Source: https://getbloggable.com/help/connect-slack

---

# Connecting Zapier, Make or n8n

Bloggable can POST a signed JSON payload to any HTTPS endpoint when something happens — a post publishes, autopilot finishes a batch, credits run low. That's enough to drive almost any automation: queue a social post, add a row to a sheet, open a ticket, notify a system that isn't Slack.

**An honest note first.** Bloggable doesn't have a published app in Zapier's or Make's directory yet, so you won't find us by searching there. You connect with a generic webhook trigger, which takes about a minute and works today.

## Setting it up in Bloggable

Same three steps whichever platform you use:

1. Create the webhook on their side and copy the URL it gives you (instructions per platform below).
2. In Bloggable, **Integrations → Webhooks** in the main nav, press **Connect** on your platform's row, and paste the URL.
3. Tick the events you want, press **Connect**, then press **Test** on the new row.

On connect, Bloggable shows you a **signing secret once**. Copy it if you plan to verify signatures — you can read it again later from the endpoint's settings, but it never appears in an email or a log.

## Zapier

1. Create a new Zap and pick **Webhooks by Zapier** as the trigger.
2. Choose the **Catch Hook** event.
3. Zapier shows you a **Custom Webhook URL** — copy it.
4. Paste it into Bloggable and press **Connect**, then **Test**.
5. Back in Zapier, click **Test trigger**. Your test event appears and Zapier learns the field names.
6. Build the rest of the Zap and publish it.

**Watch out for test URLs.** Zapier's catch hook URL is live once the Zap is published, but an unpublished Zap can stop accepting requests. If deliveries start failing with 404 after they were working, check the Zap is still on.

## Make (formerly Integromat)

1. Create a new scenario and add the **Webhooks → Custom webhook** module.
2. Click **Add**, name it, and **Save**. Make gives you an address — copy it.
3. Paste it into Bloggable, **Connect**, then **Test**.
4. In Make, the module should show "Successfully determined." — it has now learned the data structure.
5. Add the modules that do the work, and switch the scenario on.

**Make must be listening when you test.** The Custom webhook module only captures a structure while it's waiting for data. Press Bloggable's **Test** while Make shows "Waiting for data".

## n8n

1. Add a **Webhook** node to a new workflow.
2. Set the method to **POST** and copy the **Production URL** — not the Test URL.
3. Paste it into Bloggable, **Connect**, **Test**.
4. Activate the workflow.

**Use the production URL.** n8n's test URL only accepts a request while the editor is open and listening, and it expires when you close it. That's the single most common reason a working n8n connection appears to break a day later — Bloggable will tell you it got a 404 and suggest exactly this.

## Anything else

Pipedream, a Cloudflare Worker, a Lambda, or fifty lines in your own app. All Bloggable needs is an HTTPS URL that accepts a POST and answers with a 2xx. Non-public addresses are rejected when you add the endpoint — the URL has to be reachable from the internet.

## What arrives

A JSON body, flat rather than nested per event, so a Zap or an n8n node can map fields by path without a branch per event type:

```json
{
  "event": "post.published",
  "occurredAt": "2026-01-14T09:03:22.114Z",
  "account": { "id": "…", "name": "Acme" },
  "blog": { "id": "…", "name": "The Acme Blog", "url": "https://blog.acme.com" },
  "post": {
    "id": "…",
    "title": "How we cut onboarding in half",
    "slug": "how-we-cut-onboarding-in-half",
    "url": "https://blog.acme.com/how-we-cut-onboarding-in-half",
    "excerpt": "…",
    "status": "published",
    "publishedAt": "2026-01-14T09:03:21.000Z",
    "tags": ["onboarding", "product"]
  }
}
```

`blog` is absent on account-level events like `credits.low`; `post` is absent on anything that isn't about one post. Autopilot events carry counts in a `data` object instead — `drafted`, `scheduled`, `needsReview`.

### Headers

| Header | What it is |
|---|---|
| `X-Bloggable-Event` | The event id, e.g. `post.published` |
| `X-Bloggable-Timestamp` | Unix seconds — also the first half of the signed string |
| `X-Bloggable-Idempotency-Key` | Stable across retries of the same event. Dedupe on it. |
| `X-Bloggable-Signature` | `sha256=` followed by a hex HMAC-SHA256 |

## Verifying the signature

Optional — Zapier and Make can't easily check it, and plenty of workflows don't need to. Worth doing if the automation writes somewhere it matters.

The signed string is **`{timestamp}.{raw body}`**, not the body on its own. That's deliberate: a signature over the body alone stays valid forever, so anyone who captures one request could replay it indefinitely.

```js
const crypto = require('crypto')

function verify(rawBody, headers, secret) {
  const ts = headers['x-bloggable-timestamp']
  // Reject anything older than five minutes — this is what stops replays.
  if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false

  const expected =
    'sha256=' +
    crypto.createHmac('sha256', secret).update(`${ts}.${rawBody}`, 'utf8').digest('hex')

  return crypto.timingSafeEqual(
    Buffer.from(expected),
    Buffer.from(headers['x-bloggable-signature'] || ''),
  )
}
```

Two things that quietly break this: verifying a re-serialised object instead of the **raw body** you received, and comparing with `===`, which leaks the expected signature to a patient attacker one byte at a time.

## Account-wide or one blog?

An endpoint added in **Integrations → Webhooks** fires for every blog on the account, now and in future. One added from **a blog's settings → Notifications for this blog** fires only for that blog. Account-wide endpoints show up on the blog page as read-only rows marked **All blogs**, so you can see what's already listening before adding another.

## Troubleshooting

**404 on every delivery.** Almost always an expired test URL — n8n's Test URL, or a Zap that isn't published. Use the production URL and re-enable the endpoint.

**"Endpoint redirected".** Bloggable never follows redirects on a signed delivery, because a redirect would replay the signature against whatever origin it named. Point the endpoint at the final URL.

**"Timed out after 5 seconds".** Your endpoint has five seconds to answer. Acknowledge with a 200 first and do the work afterwards — most platforms have an async or queued mode for exactly this.

**"Stopped after 20 failures".** Twenty consecutive failures and Bloggable stops trying, so a dead endpoint doesn't cost every publish five seconds. Fix it, then toggle the row off and on to reset the counter.

**Duplicates.** Dedupe on `X-Bloggable-Idempotency-Key`, which stays the same across retries of the same event.

## Removing it

Delete the endpoint's row. Deliveries stop immediately, and the signing secret goes with it — reconnecting later issues a new one.

Source: https://getbloggable.com/help/connect-zapier

---

# Publishing to your own site

Write and plan in Bloggable, publish onto the site you already own. Posts are pushed to WordPress, Ghost or your own endpoint, and **your site keeps the canonical URL** — so the SEO accrues to your domain, not ours.

This is different from a custom domain. A custom domain points at a blog Bloggable hosts. This publishes into a site you host, which happens to be where the rest of your marketing already lives.

## Which one do you need?

- **[WordPress](/help/connect-wordpress)** — self-hosted WordPress, over the REST API with an application password. No plugin.
- **[Ghost](/help/connect-ghost)** — Ghost Pro or self-hosted, with an Admin API key.
- **[Webhook](/help/publish-webhook)** — a signed POST to your own endpoint, for anything else: a headless CMS, a static site generator, your own app.

One blog has one destination. That's deliberate — two would mean two canonical URLs for the same article, which is you competing with yourself in search results.

## Setting one up

It's per blog, in **Blog settings → General → Site address**, on the row that reads *Your own platform*. Not in the Integrations page — connecting involves probing your site and mapping its categories, so it lives next to the blog's other addresses because that is what it becomes.

**Integrations → Publishing** shows you which blogs are connected, whether pushes are working, and a link straight to that blog's setup.

## What happens to your Bloggable address

Once a site is connected you choose between two behaviours with the **Keep the Bloggable address live** switch:

**Off (the default)** — your Bloggable addresses redirect to the connected site. There is one copy of each post, at your address.

**On** — Bloggable keeps serving its own pages, with a canonical tag pointing at your site and the posts excluded from Bloggable's sitemap. Useful if you want a working preview or a fallback. Search engines are told plainly which copy is the original.

Either way the redirect only starts once at least one post has actually reached your site. Connecting is not publishing, and redirecting readers to an empty site would be worse than not connecting at all.

## Automatic or manual

**Publish new posts automatically** is **off** by default. With it off, a post publishes to Bloggable and waits — you push it when you're ready. With it on, publishing here publishes there.

Start with it off until you've seen a couple of posts land the way you expect.

## What we will never do

**We never delete from a site we don't own.** Unpublishing a post sets it back to draft on your site. That's the whole behaviour — there is no code path in Bloggable that issues a delete against your CMS.

**We never touch posts we didn't create.** Only posts Bloggable published are ever updated by Bloggable.

**Disconnecting doesn't unpublish anything.** Detach the connection and your posts stay exactly where they are, live on your site. Reconnecting later picks up where it left off rather than publishing 400 duplicates.

## Editing after publishing

Edit in Bloggable and the change is pushed to your site — not on every keystroke, but as a sweep after the edit settles. Editing on the far side is fine too, but the next push from Bloggable will overwrite it, so pick one place to edit and stay there.

## When something fails

The connection row shows the state: **Connected**, **Failing**, **Reconnect needed** or **Paused**. Failures name the actual problem rather than "publish failed" — an expired key, a security plugin blocking the request, a post too large for the remote server.

Retries happen on their own for anything transient. Anything that needs you (a revoked key, a site that moved) says so and stops retrying.

## Plan availability

Publishing to your own platform is on the paid tiers rather than every plan — see [Plans and billing](/help/plans-and-billing), or the row in **Settings → Add-ons**, which shows what your account has today.

Source: https://getbloggable.com/help/publish-to-your-own-site

---

# Connecting WordPress

Publish finished posts straight into your own WordPress site. They arrive as native blocks, images land in your media library, and categories, tags and byline are mapped to what already exists on the site.

**No plugin to install.** Bloggable uses WordPress's own REST API and an application password, both core features since WordPress 5.6.

## Before you start

**This is for self-hosted WordPress.** Application passwords and REST API writes aren't available on wordpress.com's lower plans, so a wordpress.com site generally can't be connected this way.

You need:

- WordPress **5.6 or later**
- The site served over **HTTPS** — we won't send credentials over plain HTTP
- An account on the site with permission to publish (Editor or Administrator)

## Step 1 — check the site

In Bloggable: **Blog settings → General → Site address → Your own platform → WordPress**.

Enter the site's **main address** — `acme.com`, not `acme.com/blog` — and press **Check site**.

This step exists so you find out about a blocker now rather than after a round trip through wp-admin. Bloggable looks at the site unauthenticated and names anything in the way:

| What you might see | What to do |
|---|---|
| **The WordPress REST API is blocked** | A security plugin or your host is blocking `/wp-json`. In Wordfence: **Firewall → Blocking**. Some hosts also have a switch in their control panel. |
| **Application passwords are turned off** | Wordfence disables these **by default**. Go to **Wordfence → Login Security → Settings** and untick *Disable WordPress application passwords*. Other security plugins have the same setting under a different name. |
| **Your host is removing the login header** | Some shared hosts strip the `Authorization` header before WordPress sees it. Add this at the top of `.htaccess`:<br>`SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1` |
| **That site is not using HTTPS** | Add an SSL certificate — most hosts provide one free — then try again. |
| **That doesn't look like a WordPress site** | Usually a subpath. Enter the site's main address instead. |

## Step 2 — create an application password

Once the check passes, Bloggable sends you to the right page in your own WordPress.

1. In WordPress: **Users → Profile**, and scroll to **Application Passwords**.
2. Type a name — "Bloggable" — and click **Add New Application Password**.
3. WordPress shows the password **once**. Copy it.

**Paste it exactly as WordPress showed it, spaces and all.** Application passwords are generated with spaces in them and they are part of the password. Stripping them is the most common cause of "those credentials were rejected".

## Step 3 — paste it into Bloggable

Enter the WordPress **username** (the one you log in with, not the display name) and the application password. Bloggable checks the account can actually publish before saving anything, and the credential is encrypted before it is stored.

## Step 4 — map it, then arm it

- **Category, tags and author** — choose what published posts should use. Bloggable reads the real lists from your site, so you pick from what exists rather than typing names and hoping.
- **Keep the Bloggable address live** — off by default, so your Bloggable addresses redirect to your WordPress site.
- **Publish new posts automatically** — off by default. Leave it off until you've watched a post land correctly.

## What arrives in WordPress

**Native blocks, not a lump of HTML.** Headings, lists, quotes, images, buttons and callouts arrive as blocks the editor understands, so the post is editable in WordPress like anything else.

**Images in your own media library.** Every image is uploaded into your library and the featured image is set. Nothing on your published post hotlinks back to Bloggable.

**Meta description**, when **Yoast** or **Rank Math** is installed to receive it.

**Embeds travel as links.** A YouTube or Spotify embed becomes an anchor rather than an iframe, because WordPress strips iframes from authors without the `unfiltered_html` capability — a link that works beats markup that gets silently removed.

## Editing, unpublishing, disconnecting

Edit in Bloggable and the change is pushed across. Unpublish and the WordPress post is set back to **draft** — never deleted. Disconnect and your posts stay live on your site, untouched; reconnecting later resumes by remote id rather than duplicating everything.

## Troubleshooting

**"Those credentials were rejected."** Check the username is the login name, and that you pasted the application password with its spaces.

**It worked, then stopped.** The application password was revoked in WordPress, or the user's role changed. Create a new one and reconnect — the row will say **Reconnect needed**.

**A post failed with "the post was too large".** Some shared hosts cap request size. Splitting a very long post, or reducing very large inline images, usually clears it.

**Everything is failing at once after a host migration.** Re-run **Check site** — the address, HTTPS certificate or REST availability may have changed.

Still stuck? [Get in touch](/help/getting-support) with the site address and the error shown on the connection row.

Source: https://getbloggable.com/help/connect-wordpress

---

# Connecting Ghost

Publish finished posts into Ghost — Ghost Pro or a Ghost site you host yourself. Images are uploaded into Ghost's own store, tags and excerpt come across, and you choose which staff user the post is published as.

The whole setup is one Admin API key.

## Before you start

You need **Administrator** access to the Ghost site, since only an admin can create a custom integration.

## Step 1 — create a custom integration in Ghost

1. In Ghost admin: **Settings → Integrations**.
2. Scroll to the bottom and click **Add custom integration**.
3. Name it — "Bloggable" — and **Create**.
4. Ghost shows three things: a Content API key, an **Admin API key**, and an API URL.

**Copy the Admin API key, not the Content API key.** This is the single most common mistake, and the two look similar at a glance. The difference is obvious once you know: an **Admin API key has a colon in the middle** — a 24-character id, a colon, then a 64-character secret. A Content API key is one unbroken 26-character string and is read-only, so it will never be able to publish.

Bloggable checks for this and tells you before you get a confusing 401.

## Step 2 — paste it into Bloggable

In Bloggable: **Blog settings → General → Site address → Your own platform → Ghost**.

1. **Site address** — the address you use to sign in to Ghost, *without* the `/ghost` part. For example `blog.acme.com`.
2. **Admin API key** — paste the full key including the colon.
3. Connect.

The connection is checked immediately, and the key is encrypted before it is stored.

## Step 3 — map it, then arm it

- **Tags** — pick the tags published posts should carry. Bloggable reads the real tag list from your site.
- **Author** — any existing staff user on the Ghost site. It has to be someone who already exists there; Ghost won't create a user for us.
- **Categories** — greyed out, because Ghost has no categories. It's disabled rather than accepted and quietly dropped.
- **Keep the Bloggable address live** — off by default, so your Bloggable addresses redirect to Ghost.
- **Publish new posts automatically** — off by default. Turn it on once you've watched a post land the way you expect.

## What arrives in Ghost

**Images in Ghost's own store.** Uploaded on the way in and rewritten in the body, so the published post doesn't depend on Bloggable staying reachable.

**Tags, excerpt and meta description**, all mapped at connect time.

**The byline you picked**, as long as that staff user still exists.

**Embeds travel as links** rather than iframes, the same as WordPress — a working link beats markup a sanitiser removes.

## Editing, unpublishing, disconnecting

Edit in Bloggable and the change is pushed to Ghost. Unpublish and the Ghost post reverts to **draft** — the public URL stops resolving and the post stays in Ghost. We never delete from a site we don't own.

Disconnecting leaves everything published exactly where it is.

## Troubleshooting

**"That looks like a Content API key."** You copied the wrong one. Go back to **Settings → Integrations**, open the custom integration, and copy the **Admin API key** — the one with a colon in it.

**"That doesn't look like a Ghost site."** Enter the address you sign in at, without `/ghost` on the end. If Ghost sits behind a proxy or on a subpath, use the address Ghost itself reports in **Settings → General**.

**"Those credentials were rejected"** after it worked. The custom integration was deleted or regenerated in Ghost. Create a new one and reconnect.

**A published post won't update.** Ghost blocks some transitions — a post moved from published back to scheduled, for instance. The connection row names what Ghost refused.

Still stuck? [Get in touch](/help/getting-support) with the site address and the error on the connection row.

Source: https://getbloggable.com/help/connect-ghost

---

# Publishing to a webhook

For any CMS Bloggable doesn't have an adapter for. Point the blog at an HTTPS endpoint and every publish, update and unpublish arrives there as JSON — the markdown and the rendered HTML both included, signed so your endpoint can prove it came from us.

Typical uses: a headless CMS (Contentful, Sanity, Strapi), a static site that rebuilds on a hook (Next.js, Astro, Hugo), or your own application.

## Is this the one you want?

There are two different webhooks in Bloggable and they do different jobs:

- **This one** — set up **per blog**, under *Site address → Your own platform*. It is that blog's publishing **destination**: the full article, in markdown and HTML, for a system that will render it.
- **[Event webhooks](/help/connect-zapier)** — set up **per account**, under *Integrations → Webhooks*. Notifications that something happened, for Zapier, Make, n8n or Slack. They carry a summary and a link, not the article body.

If you want to publish the post, you're in the right place. If you want to know that a post published, use the other one.

## Setting it up

In Bloggable: **Blog settings → General → Site address → Your own platform → Webhook**.

1. **Endpoint URL** — any HTTPS URL that accepts a POST. It has to be publicly reachable; private and loopback addresses are refused.
2. **Copy the signing secret.** Bloggable mints it and shows it **exactly once**, before the connection is created. It is stored encrypted and cannot be read back afterwards — a secret you choose is a secret you reuse, so we generate it for you.
3. **Connect.** A `ping` event goes out immediately. Verify its signature against your secret before you trust anything else.
4. **Arm it.** *Publish new posts automatically* is off by default.

## What arrives

```json
{
  "event": "post.published",
  "timestamp": 1768382602,
  "idempotencyKey": "…",
  "post": {
    "title": "How we cut onboarding in half",
    "slug": "how-we-cut-onboarding-in-half",
    "html": "<h2>…</h2>",
    "markdown": "## …",
    "excerpt": "…",
    "metaDescription": "…",
    "category": "Product",
    "tags": ["onboarding", "product"],
    "featuredImage": { "url": "https://…", "alt": "…" },
    "inlineImages": [],
    "authorName": "Sam Okafor",
    "publishedAt": "2026-01-14T09:03:21.000Z",
    "sourceUrl": "https://blog.acme.com/how-we-cut-onboarding-in-half"
  }
}
```

Events are `post.published`, `post.updated`, `post.unpublished` and `ping`. `post` is `null` on `ping` only — the key is always present, so your schema stays stable.

**Optional values are sent as explicit `null`, never omitted.** A key that disappears between posts silently breaks a live scenario, so the shape is the same every time. Changes to it will only ever be additive.

**`sourceUrl` is informational.** It is the Bloggable address, for receivers that want to link back. It is not an instruction to write a canonical pointing at us — your site is the canonical.

## Images stay as URLs

This is the one connection where images are **not** uploaded for you. Your endpoint receives absolute image URLs and decides what to do with them.

There is no media endpoint to upload to on a raw relay, so this is stated up front rather than discovered when a Bloggable CDN URL turns up in your published article. If you want the images on your own storage, download them from those URLs as part of your handler.

## Headers

| Header | What it is |
|---|---|
| `X-Bloggable-Event` | `post.published`, `post.updated`, `post.unpublished` or `ping` |
| `X-Bloggable-Timestamp` | Unix seconds — also the first half of the signed string |
| `X-Bloggable-Idempotency-Key` | Stable per post and intent. Dedupe on it and a retry never publishes twice. |
| `X-Bloggable-Signature` | `sha256=` followed by a hex HMAC-SHA256 |

## Verifying the signature

The signed string is **`{timestamp}.{raw body}`**, not the body alone. Signing the body alone produces a signature that stays valid forever, so anyone who captures one request could replay it indefinitely.

```js
const crypto = require('crypto')

// `raw` must be the RAW request body, read BEFORE JSON.parse
function verify(raw, headers, secret) {
  const ts = headers['x-bloggable-timestamp']
  const expected =
    'sha256=' +
    crypto.createHmac('sha256', secret).update(`${ts}.${raw}`, 'utf8').digest('hex')

  const received = headers['x-bloggable-signature'] || ''
  return (
    crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(received)) &&
    Math.abs(Date.now() / 1000 - Number(ts)) < 300 // five-minute window
  )
}
```

Two gotchas worth stating loudly:

1. **Verify the raw body.** Re-serialising the parsed JSON changes key order and whitespace, and the digest will not match. Most frameworks need an explicit raw-body option for this.
2. **Compare in constant time.** A byte-at-a-time `===` leaks the expected signature to a patient attacker.

## Answering

Reply with any 2xx. Bloggable treats 3xx as a failure and never follows it — a redirect from an endpoint would replay the signature against whatever origin it named.

Answer promptly and do slow work afterwards. A long rebuild that runs before the response will look like a timeout on our side.

## Troubleshooting

**404 or 410.** Usually an expired test URL rather than a deleted post — n8n's Test URL and unpublished Zapier hooks both do this. Bloggable reports it as an unreachable endpoint rather than claiming your post was deleted, because the two need completely different actions.

**Signature never matches.** You are almost certainly verifying re-serialised JSON. Read the raw body first.

**The same post arrives twice.** Dedupe on `X-Bloggable-Idempotency-Key`, which is stable across retries.

**Everything is failing.** Check the connection row in blog settings — it names the actual response we got.

## Removing it

Detach the connection in blog settings. Posts already delivered are yours and stay exactly where they are; the signing secret is destroyed, and reconnecting later mints a new one.

Source: https://getbloggable.com/help/publish-webhook

---

# Publishing posts and custom domains

## Publishing a post

From the editor's **Publish** panel:

- **Publish now** — live immediately.
- **Schedule** — pick a date and time; the scheduler runs every five minutes, so a post goes out within a few minutes of its slot.
- **Unpublish** — takes a live post back to draft.

You can also **duplicate** a post (useful as a template) and **archive** one. From the **Posts** list you can publish, archive, draft or repurpose in bulk, across blogs.

Editing an already-published post gives you a choice: edit in place, or fork a **V2 draft** so the live version stays untouched while you work.

## Where posts appear

Three possible addresses, in ascending order of ownership:

| Address | Looks like |
| --- | --- |
| Bloggable path | `getbloggable.com/b/<blog>/<post>` |
| Premium subdomain | `<handle>.bllog.io/<post>` |
| Your own domain | `blog.yourcompany.com/<post>` |

The premium subdomain is a middle tier — cheaper than a custom domain, and it looks like yours rather than ours.

Every blog also serves an RSS/Atom feed at `/feed`, `/feed.xml` and `/rss.xml`, and these follow whichever address the blog is on.

## Changing a post's URL

If you change a post's slug, the old URL permanently redirects to the new one. The same applies to a renamed blog. Nothing you've published strands a reader on a 404 because you renamed something.

## Connecting a custom domain

1. In the blog's settings, open the **Custom domain** address and add your domain — a subdomain you aren't using yet, like `blog.yourcompany.com`.
2. Follow the steps the panel then shows you: it names your DNS provider, gives you the exact record to add (every value is copy-to-clipboard), and tells you if anything already on that hostname is in the way.
3. Save the record and leave the page open, or don't — we keep checking on our own. The panel moves from **Domain added** → **DNS record** → **Certificate** as each stage completes.

Once the certificate has issued, the blog serves from your domain and that becomes its canonical address.

**If it's taking a while**, the panel tells you which of these it actually found — you don't have to guess:

- **Nothing published yet** — the record hasn't reached the public internet. Most providers take a few minutes; a few take an hour.
- **An old record in the way** — the hostname already points somewhere else. That record wins until it's deleted.
- **Cloudflare's proxy is on** — an orange cloud terminates the connection at Cloudflare, so the certificate can never be issued. Set the record to **DNS only** (grey cloud).
- **A CAA record is blocking issuance** — the domain has a CAA record that doesn't list `letsencrypt.org`, which is where our certificates come from. Add `0 issue "letsencrypt.org"`.

If the domain stops working later, we notice: every custom domain is checked once a day, and the owner gets an email naming what broke.

Custom domains are plan-dependent; **Settings → Billing** shows what your account includes.

## Why the domain matters more than it looks

**Google Search Console only works on a domain you can verify.** A blog on `getbloggable.com/b/…` or a `.bllog.io` handle sits on a domain you don't own, so Search Console will connect but will never collect data for it. If you want real click and impression data — and the decline detection in *Content intelligence* that depends on it — you need a custom domain. See *Google Search Console*.

## White-label

The white-label add-on removes Bloggable branding from the public blog: both the footer badge and the page title. Without it, the blog is still yours in every other respect, but it says where it was made.

Source: https://getbloggable.com/help/publishing-and-domains

---

# SEO and answer-engine optimisation

Bloggable optimises for two audiences at once: search engines that send you clicks, and answer engines that quote you inside an answer. They want overlapping but different things, so they're handled separately.

## SEO

The **SEO panel** in the editor generates:

- an optimised **title tag** and **meta description**
- **keywords** and a suggested **category**
- **structured data** (JSON-LD) for rich results
- **social card previews** — how the post will actually look on Google, Facebook and X

At blog level you control the default meta suffix, the canonical base, and whether the blog is indexed at all.

## AEO — being the source that gets quoted

The **AEO audit** scores how well a post can be lifted into an AI-generated answer. It measures:

- **Answer-first openings** — does the article answer the question in its first lines, or clear its throat for three paragraphs?
- **Structure** — headings that are questions, scannable sections, self-contained passages that make sense quoted alone.
- **An on-page FAQ**, with schema generated *from the visible article* so the structured data can never drift from what a reader sees.
- **Sourced claims** — assertions with something behind them.
- **Complete schema.**

The score is **computed from the document**, not asked of the model. A model rating its own output is a compliment, not a measurement.

## Internal and external links

**Internal link suggestions** cover your own published posts *and* pages from your crawled website — so a post can link into your product pages, not only into other blog posts. A retro pass can add internal links to already-published articles when new posts make new connections available.

**External link suggestions** propose authoritative outside sources. Linking out is not a leak; it's a signal both search and answer engines read as care.

The **link management panel** lists every link in the document so you can audit or remove them in one place.

## Machine-readable output

Every blog serves an `llms.txt` — a menu of your best posts for AI crawlers — and every post has a `.md` version advertised to crawlers alongside the HTML. You also control which AI crawlers may read the blog at all. See *AI crawlers and llms.txt*.

## Real data

If you connect **Google Search Console**, Bloggable syncs clicks, impressions, CTR and position nightly, and uses them to flag posts that are losing ground in **Intelligence**. Without it, you still get first-party traffic figures — views and visitors per post, no cookies or third-party scripts. See *Analytics*.

> **Search Console needs a custom domain.** Google only reports on a domain you can prove you own. A blog published to a Bloggable address (`getbloggable.com/b/…` or a `.bllog.io` handle) sits on a domain you can't verify, so Search Console will connect but collect nothing for it. Connect a custom domain to the blog first.

## Localisation

Set a blog's **target countries** and generation adapts: spelling, currency, units, examples and the regulatory framing it assumes. A UK financial post and a US one are not the same article with different spellings.

Source: https://getbloggable.com/help/seo-and-aeo

---

# AI crawlers and llms.txt

Answer engines can only cite you if they can read you. Bloggable publishes your blog in the formats they look for, and gives you explicit control over who's allowed in.

## What every blog serves

**`llms.txt`** — at your blog's root. A short, machine-readable menu of the blog and its best posts, in the emerging convention answer engines look for when asked "what is this site?".

**A `.md` version of every post** — the same article as clean markdown, at the post's URL with `.md` appended, and advertised to crawlers. HTML is full of navigation, scripts and layout; markdown is the article. Giving a model the markdown means it quotes your writing rather than your page furniture.

Both are on by default. The markdown variants can be switched off per blog if you'd rather not serve them.

## Controlling which AI crawlers may read the blog

Per blog, in the SEO settings, set the **AI-crawler policy**:

- **Allow** — an explicit permission for eleven named AI crawlers: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, anthropic-ai, PerplexityBot, Google-Extended, CCBot, Bytespider, Amazonbot and Applebot-Extended.
- **Block** — disallow them, and suppress `llms.txt`.
- **Default** — emit no named rules and let the wildcard robots.txt rule apply.

This is a real trade-off, not a formality. Blocking keeps your writing out of training data and out of AI answers. Allowing is how you get cited. Most people publishing in order to be found should allow; if the content *is* the product rather than the marketing for it, blocking may be right.

One honest limit: `robots.txt` is a request, not a fence. Well-behaved crawlers respect it.

## For your readers

Posts can carry an **"Ask AI about this article"** link that opens the post in ChatGPT, Claude, Perplexity or Kagi. It's on by default, per blog.

## Bloggable's own

We serve what we sell. Bloggable's `llms.txt` is at [/llms.txt](/llms.txt), every help article has a `.md` version, and the whole help centre is available as one file at [/help/llms-full.txt](/help/llms-full.txt) — the **Copy page** button on any help article hands it to a model directly.

Source: https://getbloggable.com/help/ai-crawlers-and-llms-txt

---

# Getting support

## Start with Joe

Joe is on every signed-in page and searches these same help articles — but with your account in front of him. He'll usually answer faster than we will, and he can often just do the thing you were about to ask how to do.

Talking to Joe is free.

## Getting a human

If Joe can't help, **ask him to escalate**. He opens a support form and hands over the conversation as context, so you don't have to re-explain what you were trying to do.

Joe doesn't create tickets on his own — the form is always yours to submit. That's deliberate: a ticket you didn't knowingly raise is a ticket you'll never see the answer to.

**If you can't sign in**, email support directly using the "Email support" button at the bottom of any help article. Mail to that address becomes a ticket the same way the in-app form does, so either route reaches the same place.

## If your account is locked

A lapsed trial or a failed payment locks the app. Escalation to a human deliberately stays available on a locked account — that's the situation most likely to need one. Joe also stays available, read-only.

See *Plans, upgrades and top-ups*.

## What to include

The more of this you can give us, the faster this goes:

- **What you expected to happen**, and what happened instead
- **Which blog and which post**, by name or URL
- **When** it happened, roughly
- Anything the interface told you — an error message, a code, a screenshot

For a billing question, say what you were charged and what you expected. For a generation that went wrong, tell us which action you ran and, if you still have it, leave the draft in place rather than deleting it.

## Things that are usually us, not you

Report these rather than working around them:

- Credits that didn't reset at the start of a cycle
- A plan showing the wrong state after a successful payment
- An action that failed but wasn't refunded — failures are supposed to refund automatically
- A published post that isn't reachable at its public URL
- A custom domain that verified and then stopped serving

Source: https://getbloggable.com/help/getting-support

---

# Troubleshooting common problems

## "Insufficient credits" when I try to generate

The action costs more than your balance. Nothing was spent and nothing half-ran. You'll be offered a top-up or an upgrade; either works. See *How AI credits work*.

## A generation failed

Failed generations are **refunded automatically** — you shouldn't be charged for one. If your balance didn't come back, tell us; that's a bug, not a policy.

If the same action keeps failing, try a narrower topic. Very broad subjects sometimes produce a research pass with nothing specific enough to write against.

## My chosen blog slug is taken

Slugs are unique across all of Bloggable, not just your account, so common words go early. Pick another, or use a custom domain, where the address is entirely yours. See *Creating and configuring blogs*.

## My custom domain won't verify

In order of likelihood:

1. **DNS hasn't propagated.** Give it a few hours.
2. **The record is wrong.** Check the type and value exactly as displayed.
3. **It's behind a proxy.** Try DNS-only (Cloudflare's grey cloud) until verification passes.
4. **Wrong zone.** `blog.example.com` goes in the `example.com` zone.

See *Publishing posts and custom domains*.

## Search Console is connected but shows no data

Almost always because the blog isn't on a custom domain — Google can only report on a domain you can verify. See *Connecting Google Search Console* for the full list of causes.

## A published post isn't showing on my blog

Check, in this order: that it's actually published rather than scheduled; that the blog isn't paused or archived; that you're looking at the right address if the blog has both a Bloggable path and a custom domain; and that the blog's SEO settings haven't disabled indexing (which affects search engines, not whether the page loads).

If you renamed the post or the blog, the old URL should redirect rather than 404 — if it doesn't, report it.

## Autopilot isn't producing anything

- **Check the level.** At topic-discovery level it plans but never writes; at auto-draft level it drafts but never publishes.
- **Check for unapproved topics.** Nothing gets written from a topic still waiting for your yes.
- **Check the budget cap.** If it's hit its monthly ceiling it stops until the next cycle.
- **Check the quality gate.** Drafts below your word count, AEO score or AI-integrity thresholds are held back, by design. The activity log says which.
- **Check the blog isn't paused.** Pausing a blog stops autopilot.
- **Check your credit balance.**

The **activity log** records every run and why it did what it did. Start there.

## Autopilot notifications aren't arriving

Failure emails do send. The per-event toggles in the setup wizard — planned topic added, draft ready, published — are **not yet wired up** and currently do nothing. This is a known gap, not a misconfiguration at your end.

## Joe won't do something I asked

Three possible reasons: your **role** doesn't allow it (viewers can ask but not change; personas and archiving need admin), your **account is locked**, or it's something Joe deliberately never does — anything touching payment. See *Meet Joe*.

## Still stuck

See *Getting support*.

Source: https://getbloggable.com/help/troubleshooting

---

# Writing posts with AI

Posts are written in the full-screen **editor**, opened from **Posts**. Markdown is the source of truth — blocks, formatting and media round-trip cleanly, so nothing is trapped in a proprietary format.

Every AI action that generates content spends credits. Manual editing is free, and so is asking Joe about a post.

## Ways to generate a draft

**Full pipeline** — research → draft → SEO → internal links in one pass. The default for a post you want ready to review. Costs more than the individual steps because it *is* the individual steps.

**Draft from a topic** — you give the topic, the AI streams a first draft against your blog's niche, audience and voice. No live research, so it's cheaper and faster, and better suited to subjects where you supply the substance.

**Research first, then draft** — a live web research pass gathers real sources, statistics and competitor gaps, then the draft is written against those findings. Use it for anything where being wrong is expensive.

**Inline AI** — with a post open, use the slash menu (`/`) or select a passage and choose an AI edit. Drafts or rewrites *at your cursor* rather than regenerating the article. The cheapest AI action there is, and the one you'll use most.

## Making a draft actually good

**Improve** targets the article's own weakest scoring signals rather than rewriting indiscriminately — it reads the score breakdown and fixes what's dragging it down.

**Humanise** strips the patterns that make AI writing recognisable: uniform sentence rhythm, hedging, tidy tricolons, the summary paragraph that repeats the intro. It then re-applies your brand voice.

**Redraft from feedback** takes your written notes — "too long, and it never says who this is for" — and repositions the article accordingly. This is a strategic rewrite, not a polish.

**Track changes** shows AI edits as a word-level diff you can review and undo, so an AI pass is never a black box you have to accept whole.

## The scores

The editor shows a live **content score** — a composite of how human the writing reads, the AEO score, SEO signals and readability.

The **human-ness score** is a 0–100 rating with the specific passages that triggered it flagged. Each flag has a one-click fix, which does a surgical find-and-replace rather than a full rewrite. It is a heuristic, not a guarantee about any particular third-party detector, and it should be read as "this reads like a machine wrote it" — which is a writing problem regardless of who's checking.

The **AEO audit** is computed from the document, not asked of the model. See *SEO and answer-engine optimisation*.

## Working with a published post

Editing a live post gives you a choice: edit in place, or fork a **V2 draft** and work on that while the current version stays live. Use the fork when the change is substantial enough that a half-finished edit would embarrass you in public.

**Refresh** rewrites an ageing article while keeping its URL, which preserves whatever ranking and backlinks it has earned. It's the right tool for a post that used to perform and no longer does — *Content intelligence* will tell you which ones those are.

## Getting better output

- **Fill in the niche and audience properly.** They are used on every generation.
- **Set a brand voice.** It's free and it changes every draft. See *Brand voice*.
- **Add your competitors.** Research uses them to find the angle nobody has taken.
- **Add reusable elements.** Your standard CTA, disclaimer or product callout can be injected automatically instead of pasted every time. See *Reusable elements*.
- **Edit the parts only you know.** The AI can research and structure. It cannot supply your customer's actual objection, last quarter's real number, or the thing you learned the hard way — and those are what make a post worth reading.

Source: https://getbloggable.com/help/writing-with-ai

---

# The editor

Posts are written in a full-screen block editor. **Markdown is the source of truth** — everything you build round-trips to markdown and back, so nothing you write is locked into Bloggable's format.

You can switch between the rich editor and raw markdown at any time.

## Slash commands

Type `/` anywhere to insert a block without leaving the keyboard. That's the fastest way to reach any of the eighteen content blocks: callouts, CTAs, buttons, toggles, galleries, vouchers, quotes, code, tables and the rest.

## Paste-to-embed

Paste a URL and it becomes an embed or a bookmark card automatically. YouTube, Vimeo, Spotify, SoundCloud, CodePen and X are recognised as media; anything else becomes a link card.

## AI where your cursor is

Select a passage, or use the slash menu, to run an AI edit on *that text* rather than the whole article. This is the cheapest AI action in the product and the one worth building a habit around. See *Writing posts with AI*.

## The panels

- **Sidebar** — post metadata: title, slug, excerpt, featured image, author, category, tags.
- **SEO panel** — title tag, meta description, keywords, structured data, and previews of how the post will look on Google, Facebook and X.
- **Content score** — live composite of human-ness, AEO, SEO and readability, with specific flagged passages and one-click fixes.
- **Link panel** — every link in the document, in one list, so you can audit or remove them.
- **Publish panel** — publish, schedule, unpublish.

## Saving

The editor autosaves as you work; there's no save button to forget. Editing an already-published post asks whether you want to change the live version or fork a V2 draft.

## Reusable elements

Anything you paste into every post — a CTA, a disclaimer, a product callout — should be a reusable element instead. Save it once and have it injected automatically, including by autopilot. See *Reusable elements*.

## What isn't there yet

- **Revision history.** There's no version timeline to roll back through; the V2 draft fork is the safety net for substantial edits to live posts.
- **A media library browser.** You can upload images, but there's no screen for managing what you've already uploaded. See *Images and media*.

Source: https://getbloggable.com/help/the-editor

---

# Images and media

## Getting an image into a post

Four routes, all from the featured-image picker or the editor:

- **Upload** your own — drag and drop, or pick a file.
- **Unsplash** — a built-in library of free photography, attributed automatically as their licence requires.
- **By URL** — paste a link to an image you host elsewhere.
- **AI-generated cover** — Bloggable generates one for the post. This costs credits, unlike the other three.

Autopilot can pick a featured image for you automatically, as an optional stage. See *Autopilot*.

## Video and social embeds

Paste a URL and it becomes an embed: YouTube, Vimeo, Spotify, SoundCloud, CodePen and X are recognised. Everything else becomes a bookmark card. See *The editor*.

## Storage

Uploads count against a per-plan storage quota — **Settings → Billing** shows yours. Unsplash images and images referenced by URL don't consume it, since they aren't hosted by us.

## Alt text

Write it. It's an accessibility requirement first, and both search engines and answer engines read it. An article that scores well on AEO and ships images with no alt text is only half-finished.

## What isn't there yet

There's **no media library browser** — you can upload images, but there's no screen listing everything you've uploaded to reuse or tidy up. Plan to re-upload or use a URL if you need the same image across several posts, or make it part of a reusable element.

Source: https://getbloggable.com/help/images-and-media

---

# Reusable elements

A **reusable element** is a block you save once and have inserted into posts automatically — your standard call-to-action, a compliance disclaimer, a product callout, a newsletter prompt.

It replaces the habit of pasting the same paragraph into every article and then discovering, six months later, that eleven versions of it are in circulation.

## Saving one

Build the block in the editor, then save it to your account's element library. It's stored as a real block, not as flat text, so a saved CTA is still a CTA with its button and styling intact.

## Placement rules

An element isn't just available — it can be *placed*. You set where it appears and when, and Bloggable injects it into posts that match, including posts written by autopilot.

The rule worth understanding is **funnel-stage targeting**: a bottom-of-funnel CTA can be set to appear only on bottom-of-funnel posts. A hard sell on an introductory explainer converts nobody and costs you the reader; the same CTA on a comparison post is exactly right. Autopilot already balances its output across funnel stages, so the two features work together.

## Editing

Update the element and the change flows through where it's placed — that's the point of it existing. Deleting an element needs admin.

## Joe can do this too

Joe can save an element, list what you have, place one, and update one. Deleting is admin-only, as it is everywhere else.

## Note on snippets

Reusable elements supersede the older "snippets" concept and the editor's **Save snippet** action. Use elements.

Source: https://getbloggable.com/help/reusable-elements

---

# Repurpose a post for social

**Repurpose** turns a published post into channel-native copy you can paste
straight into your social accounts — a LinkedIn post, an X (Twitter) thread, a
short caption for Instagram/Threads/Facebook, or a one-line bio blurb.

It works on **published posts only**: the generated copy links back to the live
article, so there needs to be a public URL to point at.

## How to use it

From the **Posts** list, open the `···` menu on any published post and choose
**Repurpose…**. You can also do it from the editor's top bar (the megaphone
icon) while viewing a published post, or straight after you publish.

1. **Pick your destinations.** Each one shows its credit cost. LinkedIn and X are
   selected by default. LinkedIn comes back as three distinct angles — contrarian,
   practical and story — rather than one take you have to accept.
2. **Generate.** Each destination is written separately, so if one fails only
   that one is affected — the rest still come through, and a failed one is
   refunded.
3. **Edit and copy.** Tweak the wording (your edits are saved), then use the
   copy button on each card. The article link is added for you in the right place
   for each platform.

Your original post is never changed.

## Credits

Repurposing is charged **per destination**, so you only pay for the formats you
generate. Generating LinkedIn and an X thread for one post is two destinations.
You'll always see the total before you spend, and you can't start a run you
can't afford.

**Regenerating** a destination is free the first time each day, and always free
when your edits to the post have made the existing version out of date.

## Doing several posts at once

Select multiple published posts in the **Posts** list and click **Repurpose**.
You'll pick the destinations once, see the total cost with your balance, and can
skip posts that already have that copy. There's a progress bar and a live credit
counter, and you can stop partway — anything already generated is kept.

## Asking Joe

Joe can do it too: *"repurpose my latest post for LinkedIn"*. For more than one
post Joe will show you the cost first and ask you to confirm. You can also ask
*"what did you write for LinkedIn?"* and Joe will read it back for free without
regenerating.

## What's not included yet

Repurpose creates the copy for you to post yourself — it doesn't post or schedule
to social networks directly, and it doesn't add images. Newsletter/email copy
isn't a destination yet.

Source: https://getbloggable.com/help/repurpose

---

# Legal

Source: https://getbloggable.com/legal

---

---
title: "Terms of Service"
effective: 2026-09-05
version: "1.0"
source: "https://getbloggable.com/legal/terms"
---

# Terms of Service

Effective 5 September 2026 · Version 1.0

> **In plain English.** Bloggable is an AI blogging platform run by Referr Ltd, a UK company. You keep ownership of everything you write or generate. Plans renew automatically until you cancel, which you can do at any time from Settings → Billing. AI features cost credits; your monthly allowance resets each cycle and top-ups carry over. AI output can be wrong, so you must review it before you publish it: you are the publisher of your blog. We do not use your content to train AI models. This summary is here to help; the numbered clauses below are the contract.

## 1. Who we are and how these Terms work

1.1 These Terms of Service (the **"Terms"**) are a contract between you and **Referr Ltd**, a company registered in England and Wales under company number 14651607, whose registered office is at 2nd Floor College House, 17 King Edwards Road, Ruislip, London, HA4 7AE, United Kingdom. We trade as **Bloggable**. In these Terms, **"we"**, **"us"** and **"our"** mean Referr Ltd, and **"you"** and **"your"** mean the person or organisation using the Services.

1.2 The Terms apply to our websites at getbloggable.com and bllog.io, the Bloggable application, our APIs, and every feature we provide through them (together, the **"Services"**).

1.3 The following documents form part of the Terms and are incorporated by reference:

- our [Privacy Policy](/legal/privacy), which explains how we handle personal data;
- our [Acceptable Use Policy](/legal/acceptable-use), which sets out what you may and may not do or publish using the Services;
- our [Cookie Policy](/legal/cookies);
- our [Data Processing Addendum](/legal/dpa), which applies where we process personal data on your behalf; and
- the plan, price, allowance and limits shown to you on the Plans page and at checkout when you place an order (your **"Order"**).

1.4 You accept the Terms by creating an account, clicking to accept them, or using the Services. If you are accepting on behalf of a company or other organisation, you confirm that you have authority to bind it, and "you" means that organisation.

1.5 The Services are designed for businesses, professionals and organisations. If you are a **consumer** (an individual acting wholly or mainly outside your trade, business, craft or profession), clause 16 applies to you and takes priority over anything in these Terms that would reduce your statutory rights.

1.6 If there is a conflict between the documents that make up the Terms, the following order applies: (a) the Data Processing Addendum, for matters of data protection only; (b) your Order; (c) these Terms; (d) the Acceptable Use Policy; (e) the Privacy Policy and Cookie Policy.

## 2. Definitions

**"Account"** means the Bloggable workspace created for you or your organisation, including every blog, post, member and setting within it.

**"AI Features"** means every part of the Services that uses machine-learning models, including research, drafting, editing, scoring, image selection, repurposing, Autopilot and Joe.

**"Autopilot"** means the feature that discovers topics, drafts posts and, at the level you choose, publishes them on a schedule without a person pressing publish.

**"Credits"** means the units of AI usage described in clause 6.

**"Customer Content"** means everything you or your Members upload, import, enter, connect or generate through the Services, including posts, images, voice samples, brand guidelines, competitor and content-source URLs, and Output.

**"Input"** means the text, files, settings and instructions you give to an AI Feature.

**"Joe"** means the in-app AI assistant that answers questions about, and takes actions in, your Account on your instruction.

**"Member"** means a person you invite to your Account, in any role.

**"Output"** means text, structured data, scores, suggestions and other material that an AI Feature generates in response to Input.

**"Plan"** means the subscription tier, trial or free tier under which you use the Services, including any add-ons.

**"Third-Party Service"** means any product or service that is not ours but that the Services connect to or rely on, such as Google Search Console, WordPress, Ghost, Stripe or Unsplash.

## 3. The Services

3.1 Bloggable lets you create and host blogs, research and write articles with AI in your own voice, optimise them for search engines and AI answer engines, monitor performance, repurpose articles for other channels, and, with Autopilot, run that loop on a schedule. The features available to you depend on your Plan.

3.2 We improve the Services continuously. We may add, change or remove features, and may change the models, providers and techniques behind the AI Features, provided that we do not materially reduce the core functionality of your paid Plan during a period you have already paid for without giving you notice and the right to cancel under clause 20.

3.3 Some features may be labelled beta, preview, experimental or similar. They are provided for evaluation, may be changed or withdrawn without notice, and are excluded from any commitments we make about availability or performance.

3.4 Support is provided through Joe, the [Help centre](/help) and email at hello@support.getbloggable.com. We aim to respond to support requests within two business days (Monday to Friday, excluding public holidays in England). Unless your Order says otherwise, response times are targets, not guarantees.

## 4. Your Account

4.1 You must be at least 18 years old to create an Account or use the Services.

4.2 You must give us accurate, current information when you sign up and keep it up to date. You sign in with a Google account or with a link we email to you, so you are responsible for keeping those accounts secure. You must tell us at hello@support.getbloggable.com promptly if you believe your Account has been accessed without authority.

4.3 An Account has one **owner** and may have Members in the roles of admin, member or viewer. The owner is responsible for the Account, for everything done through it by Members, and for ensuring that Members comply with the Terms. If you invite a Member, you confirm that you may share the Account's content and data with them.

4.4 You are responsible for everything that happens under your Account, whether or not you authorised it, unless it results from our breach of these Terms.

4.5 Our staff access Accounts only where necessary to provide support you have asked for, to investigate a security incident or suspected breach of the Terms, to comply with the law, or to operate and maintain the Services. Staff access is role-restricted and logged.

## 5. Plans, trials and billing

5.1 **Plans.** The features, credit allowance, blog and member limits, storage and add-ons for each Plan are those published on the Plans page and shown at checkout when you order. We may change the composition of Plans offered to new customers at any time; changes to your existing Plan are governed by clauses 5.6 and 20.

5.2 **Free trials.** We may offer a free trial when you first subscribe. The length of the trial is shown at checkout. To start a trial you must provide a valid payment method. Unless you cancel before the trial ends, your subscription starts automatically at the end of the trial and your payment method is charged for the first billing period. We will remind you by email before the trial ends. Each customer, organisation and payment method is entitled to **one** free trial. A trial includes the full monthly Credit allowance of the Plan you choose; a further allowance is granted at the start of each billing period once the trial converts.

5.3 **Subscriptions renew automatically.** Paid Plans are subscriptions. They renew at the end of each billing period (monthly, or annually where offered) for a further period of the same length, and your payment method is charged in advance at each renewal, until you cancel. You may cancel at any time under clause 5.8.

5.4 **Payment.** Payments are processed by Stripe. By providing a payment method you authorise us and Stripe to charge it for the Plan, add-ons, Credit top-ups and applicable taxes when they fall due. We never see or store your full card details. If a payment fails we will retry it and notify you; if it remains unpaid after Stripe's retry period we may **lock** your Account (clause 19.3), which pauses the app and Autopilot but does not delete your content. You can reactivate by settling the amount due or choosing a Plan.

5.5 **Prices and taxes.** Prices are shown in the currency you select at checkout. Prices exclude VAT and any other applicable taxes unless the checkout says otherwise; where we are required to charge VAT it is added at the prevailing rate. You are responsible for any other taxes or bank charges that apply to you. The price shown at checkout for a currency is the price charged in that currency.

5.6 **Price changes.** We may change the price of your Plan by giving you at least 30 days' notice by email. The new price takes effect at your next renewal after the notice period. If you do not want to pay the new price you may cancel before it takes effect and your subscription will end at the end of your current period.

5.7 **Changing Plan.** You can change Plan in the app.

- An **upgrade** takes effect immediately. You are charged the prorated difference for the rest of the current billing period, and the difference in Credit allowance is added to your balance straight away.
- A **downgrade** takes effect at your next renewal. There is no refund or proration for the remainder of the current period; you keep your current Plan, limits and Credit balance until then. A downgrade never removes the address of a blog you already have (clause 9).
- **Add-ons** (such as an extra blog or white-label branding) are billed with your Plan at the price shown for your tier and can be removed at any renewal.

5.8 **Cancellation.** You can cancel your subscription at any time from **Settings → Billing**, which opens the Stripe billing portal, or by emailing hello@support.getbloggable.com. Cancellation takes effect at the end of the billing period you have already paid for. You keep full access until then. Except where clause 16 or clause 19.4(d) applies, we do not refund fees for any part of a period that is unused, including where you stop using the Services before the period ends.

5.9 **Basic tier.** After a trial ends or a subscription lapses, you may choose to move your Account to the free Basic tier where we offer it. Basic has no subscription fee, no monthly Credit allowance, and reduced limits; AI Features run only on Credits you buy. Your published content stays live within the Basic limits.

5.10 **Refunds.** Fees are non-refundable except (a) as required by law, (b) as set out in clauses 16 and 19.4(d), or (c) where we decide, in our discretion, to make a refund or give a credit. Requests should be sent to hello@support.getbloggable.com.

5.11 **Invoices and disputes.** Invoices and receipts are available from Settings → Billing. If you believe a charge is wrong, tell us within 30 days of the invoice date and we will investigate promptly; we will not treat an amount you have disputed in good faith as overdue while we do so.

## 6. AI Credits

6.1 AI Features consume **Credits**. The number of Credits an action costs is shown in the app before you run it; an action that would take you below zero does not start. Chatting with Joe, editing by hand and extracting a brand voice do not consume Credits. We may change the Credit cost of an action from time to time; the cost shown in the app when you run an action is the cost you pay.

6.2 **Monthly allowance.** Each paid Plan includes a monthly allowance of Credits. The allowance is granted at the start of each billing period. Unused allowance **expires at the end of the period and does not roll over**.

6.3 **Top-ups.** You may buy additional Credits as one-off top-ups at the price for your Plan. Top-up Credits do not expire at the end of the billing period; they remain available for 12 months from purchase or until your Account is closed, whichever is earlier, and are spent only after your monthly allowance for the period is used.

6.4 **Trial Credits.** A free trial includes the full monthly Credit allowance of the Plan you choose. Trial Credits are forfeited if you cancel during the trial (clause 6.7).

6.5 **Failed actions are refunded.** If an AI action fails before it produces a result, the Credits deducted for it are automatically returned to your balance. Credits are not returned for an action that completes but produces Output you are unhappy with; you can always review the cost, and Autopilot's per-blog budget cap, before running an action.

6.6 **Nature of Credits.** Credits are a unit of measurement for your use of the Services. They have no cash value, cannot be transferred between Accounts, cannot be exchanged for money, and are not refundable except as required by law. Credits are pooled across every blog and Member in an Account.

6.7 **Forfeiture.** Credits from your monthly allowance and any promotional or trial Credits are forfeited if you cancel during a trial, move to the Basic tier, or your Account is closed or terminated. Purchased top-up Credits survive a cancellation, downgrade or move to Basic while your Account remains open, but are forfeited when the Account is closed or terminated for breach.

6.8 We may suspend or reverse Credit grants obtained by fraud, by abuse of trials or promotions, or in breach of the Terms.

## 7. Your Content

7.1 **You own your content.** You retain all intellectual property rights in Customer Content. Nothing in these Terms transfers ownership of your content to us.

7.2 **Licence to us.** So that we can provide the Services, you grant us a worldwide, non-exclusive, royalty-free licence to host, store, reproduce, transmit, display, adapt (for example, to render, format, resize or convert it) and otherwise process Customer Content, and to make it available to the public and to Third-Party Services in the way you configure. This licence lasts for as long as your content is on the Services and for a short period afterwards while it is removed from caches and backups. We do not use Customer Content for any purpose other than providing, securing and improving the Services as described in our Privacy Policy, and we do not use it to train machine-learning models (clause 8.3).

7.3 **Your responsibilities.** You are responsible for Customer Content. You confirm that:

- you own or have all rights needed for the content you upload, import or connect, including content imported from an existing blog and any images, quotations and third-party material within it;
- you have the right to instruct the Services to crawl or analyse any website you add as a content source or competitor, and that doing so does not breach that website's terms or the law;
- Customer Content, and your use of the Services, complies with the law, the Acceptable Use Policy and the rights of others; and
- content you publish complies with advertising, consumer-protection and disclosure rules that apply to you, including the UK Advertising Codes and the Digital Markets, Competition and Consumers Act 2024.

7.4 **Published content is public.** Anything you publish to a blog is available to the public and may be read, cached, indexed and quoted by search engines, AI systems and anyone else. The AI-crawler controls in the Services work by publishing instructions in robots.txt and llms.txt that well-behaved crawlers honour; we cannot guarantee that every crawler will comply.

7.5 **Removal and takedown.** We do not routinely monitor Customer Content, but we may review, remove, unpublish or disable access to content, or to a whole blog, where we reasonably believe it breaches the Terms or the Acceptable Use Policy, where we receive a credible notice of infringement or unlawfulness, or where the law requires us to. Where practicable we will tell you and give you a chance to fix the problem. The notice-and-takedown procedure is in the Acceptable Use Policy.

7.6 **Export and backups.** We keep backups for operational purposes, but you are responsible for keeping your own copies of content that matters to you. Every published post is available in Markdown from its URL, and you can export content from the app at any time while your Account is open.

7.7 **Feedback.** If you give us suggestions or feedback, we may use them without restriction or payment. This does not give us any right to your Customer Content.

## 8. AI Features

8.1 **What AI is and is not.** Output is generated by large language models operated by third parties and orchestrated by us. Models predict text; they do not verify facts. Output may be inaccurate, incomplete, out of date, biased, or unsuitable for its purpose, may state things confidently that are false, and may resemble content that already exists elsewhere. **You must review Output before you rely on or publish it.** You are the publisher of whatever appears on your blogs and other channels, including content that Autopilot publishes on your behalf.

8.2 **Ownership of Output.** As between you and us, and to the extent permitted by law, you own the Output generated for you, and we assign to you any rights we may hold in it. You acknowledge that the legal protection available for AI-generated material is uncertain, that similar or identical Output may be generated for other customers, and that we cannot guarantee that Output is original or does not infringe a third party's rights. We claim no rights in Output and give no warranty about it beyond clause 15.

8.3 **We do not train on your content.** We do not use Input, Output or Customer Content to train or fine-tune machine-learning models, and we require our AI providers not to do so. Content submitted to AI Features is processed to generate your result and, where our providers retain it briefly, that is for abuse prevention and operational reliability under contractual limits. Joe may remember your stated preferences to personalise future work; that memory is scoped to your Account, personal data is redacted before it is stored, and you can ask Joe or us to forget it.

8.4 **Research and sources.** The research features search the public web through a third-party search provider and cite sources. Sources are chosen by an automated process; we do not vouch for their accuracy or their right to be quoted. You are responsible for checking sources and for using any third-party material lawfully.

8.5 **Personas and disclosure.** The Services let you attribute posts to a **persona**, a named author profile that may not correspond to a real person. You may use personas for house style and editorial voice, but you must not use them to mislead readers or to claim credentials, experience, reviews or endorsements that do not exist. Whether and how you disclose AI involvement in your content is your responsibility under the laws and platform rules that apply to you.

8.6 **Autopilot.** Autopilot acts on the settings you choose, including the level of automation, the volume of content, the budget cap and the quality thresholds. At its fully automated level it will publish content in your name without a person reviewing it first. By enabling that level you accept that risk. Autopilot pauses automatically when your Account is locked or when it would exceed your Credit balance or budget cap, and we may pause it where we reasonably believe it is producing content in breach of the Terms.

8.7 **Joe.** Joe can take actions in your Account, such as planning topics, drafting posts and changing settings, on your instruction. Joe asks for confirmation before destructive actions. You are responsible for the instructions you give Joe. Joe cannot buy Credits, change your Plan or access payment details.

8.8 **Prohibited uses of AI Features** are set out in the Acceptable Use Policy.

8.9 **Not professional advice.** Output is not legal, financial, medical, tax or other professional advice, however it is phrased.

## 9. Hosting, addresses and domains

9.1 **Blog addresses.** Each blog has an address on our hosting: a path on getbloggable.com, and, on eligible Plans, a **premium handle** subdomain of bllog.io and/or a custom domain that you own. Addresses are allocated on a first-come, first-served basis. We may refuse or withdraw an address that infringes someone's rights, impersonates a person or organisation, is misleading or offensive, or breaches the Acceptable Use Policy. Addresses have no cash value and cannot be sold or transferred outside the Services.

9.2 **Renaming.** If you change a blog's address we redirect the old one for a reasonable period. A path-based address you release may be reused by someone else; a premium handle you release is retired and is not reallocated.

9.3 **Custom domains.** You may connect a custom domain that you own or control. You are responsible for your domain registration, its DNS configuration and its renewal. You must not connect a domain that belongs to us, to our hosting providers, or to anyone who has not authorised you. We provision TLS certificates for connected domains automatically; we may disconnect a domain that fails verification, expires, or is used in breach of the Terms.

9.4 **Attribution.** Blogs display a small "Powered by Bloggable" notice unless your Plan includes white-label branding.

9.5 **Availability.** We use reasonable endeavours to keep the Services available around the clock, but we do not promise uninterrupted or error-free operation. The Services depend on third-party infrastructure and may be affected by maintenance, capacity limits, outages of Third-Party Services, and events outside our control. We will try to schedule planned maintenance outside UK business hours and to give notice of it. Any service-level commitment applies only if your Order includes one.

9.6 **Limits.** Storage, bandwidth and rate limits apply to keep the Services reliable for everyone. We may throttle or limit use that is abnormal for your Plan and will tell you if we do.

9.7 **Traffic statistics.** We count views of your blogs using a first-party, cookieless method described in our Privacy Policy. Counts are approximate and are provided for your information only.

## 10. Third-Party Services and integrations

10.1 The Services can connect to Third-Party Services, including Google Search Console, WordPress, Ghost and custom webhook endpoints. When you connect one, you authorise us to access it and to act on it on your instruction, including publishing and updating content there. We store the credentials you provide encrypted, use them only for the connection, and delete them when you disconnect.

10.2 Third-Party Services are governed by their own terms and privacy policies. We are not responsible for them, for their availability, or for what happens to content once it is delivered to them. You are responsible for complying with their terms and for keeping the accounts you connect secure.

10.3 Images sourced through the Unsplash integration are licensed to you under the Unsplash License, not by us. You must comply with it, including any attribution it asks for.

10.4 Payments are handled by Stripe under Stripe's terms of service, which apply to your use of the billing portal and checkout.

10.5 Content that you embed in posts from third-party platforms (such as video, audio or social media) is loaded from those platforms and may set cookies or collect data from your readers. You are responsible for any notice or consent your readers require.

## 11. Acceptable use

11.1 You must comply with the [Acceptable Use Policy](/legal/acceptable-use). It is part of these Terms.

11.2 You must not, and must not allow anyone else to: (a) copy, modify, translate, reverse-engineer, decompile or create derivative works of the Services or any part of them, except as the law allows; (b) resell, sublicense, rent or provide the Services to third parties as a service bureau, except that agencies may operate blogs for their clients within the limits of their Plan; (c) access the Services by automated means other than our published APIs and the features we provide, or scrape, harvest or extract data from them; (d) use the Services to build a competing product or to create training data for a machine-learning model; (e) interfere with or disrupt the Services or their security; (f) probe, scan or test the vulnerability of the Services without our written permission (see our [Trust Centre](/trust) for how to report a vulnerability); or (g) remove or obscure any proprietary notice.

## 12. Intellectual property

12.1 The Services, including the software, the design, the themes, the documentation, the help content, Joe, and the Bloggable name and logo, are owned by us or our licensors and are protected by intellectual property laws. Except for the limited rights expressly granted in these Terms, we reserve all rights.

12.2 Subject to the Terms, we grant you a limited, non-exclusive, non-transferable, revocable licence to access and use the Services during the term of your Account for your own business or personal purposes.

12.3 Themes are licensed for use on blogs hosted by the Services. You may customise a theme for your blogs, but you may not extract, redistribute or use a theme outside the Services.

12.4 You may not use the Bloggable name, logo or trade marks without our prior written consent, except to state truthfully that your blog is hosted on or built with Bloggable.

12.5 We may collect and use data about how the Services are used, in aggregated or de-identified form that does not identify you or any person, to operate, secure and improve the Services.

## 13. Confidentiality

13.1 Each of us will keep confidential any non-public information disclosed by the other in connection with the Services that is marked confidential or would reasonably be understood to be confidential, and will use it only for the purposes of the Terms. Unpublished Customer Content is your confidential information; the non-public parts of the Services are ours.

13.2 This obligation does not apply to information that is or becomes public through no fault of the recipient, was already lawfully known to the recipient, is independently developed, or must be disclosed by law or by a court or regulator (in which case the recipient will, where lawful, tell the other party first).

## 14. Data protection

14.1 Each of us will comply with the UK GDPR, the Data Protection Act 2018 and the Privacy and Electronic Communications (EC Directive) Regulations 2003 (**"Data Protection Law"**) in connection with the Services.

14.2 We are a **controller** of the personal data we collect about you and your Members to operate your Account, bill you, secure the Services and communicate with you. Our Privacy Policy explains that processing.

14.3 We are a **processor** of personal data contained in Customer Content and of the limited data we collect about visitors to your blogs on your behalf. The Data Processing Addendum governs that processing and applies automatically to every Account that includes such data.

14.4 You are responsible for having a lawful basis for the personal data you include in Customer Content, for giving your readers any privacy or cookie notice they require, and for responding to their rights requests. We will help as the Data Processing Addendum describes.

## 15. Warranties and disclaimers

15.1 Each of us warrants that it has the authority to enter into these Terms.

15.2 We warrant that we will provide the Services with reasonable care and skill and substantially as described on our website. If we fail to do so, tell us and we will use reasonable endeavours to fix the problem; if we cannot, you may cancel under clause 19.2 and we will refund any fees you have paid for the period after cancellation.

15.3 Otherwise, and to the fullest extent permitted by law, the Services and Output are provided **"as is"** and **"as available"**. We do not warrant that the Services will be uninterrupted, secure or error-free, that Output will be accurate, original, complete or fit for any purpose, or that use of the Services will achieve any particular result, including search rankings, traffic, citations by AI systems, revenue or engagement. Any statistics, scores, forecasts or estimates in the Services are indicative only.

15.4 If you are a business customer, all warranties, conditions and terms implied by statute or common law, including those in the Supply of Goods and Services Act 1982, are excluded to the extent permitted by law.

15.5 Nothing in this clause affects the rights of consumers described in clause 16.

## 16. If you are a consumer

16.1 This clause applies only if you are a consumer as defined in clause 1.5. If it conflicts with any other clause, this clause wins.

16.2 **Your statutory rights.** Under the Consumer Rights Act 2015 we must provide the Services with reasonable care and skill, and digital content must be as described, fit for purpose and of satisfactory quality. Nothing in these Terms limits those rights. For advice about your rights contact Citizens Advice or your local Trading Standards office.

16.3 **Your right to cancel within 14 days.** You have the right to cancel the contract within 14 days of the day you subscribed (the **"cancellation period"**), without giving a reason. By subscribing you ask us to start providing the Services immediately, including during the cancellation period. If you cancel within the cancellation period you will pay only for the Services provided up to the point you cancel, in proportion to the full price of the period; where you cancel during a free trial nothing is payable. To cancel, use Settings → Billing, email hello@support.getbloggable.com, or write to us at our registered office. You may use this wording: "I give notice that I cancel my contract for Bloggable services. Name: ___. Email address of account: ___. Date: ___." We will confirm receipt by email and refund any amount due within 14 days using the payment method you used, without charge.

16.4 **Renewals, reminders and cooling-off.** Before a free trial converts to a paid subscription, and before a renewal, we will send you a reminder by email that tells you the date and the amount and how to cancel. Where the law gives you a cooling-off period after a trial converts or after a renewal, you may cancel within that period and we will refund you in the same way as under clause 16.3. You can cancel at any other time under clause 5.8 and your subscription will end at the end of the period you have paid for.

16.5 **Refunds where the service is faulty.** If the Services are not provided with reasonable care and skill, or digital content is faulty, you may be entitled to a repeat performance or a price reduction under the Consumer Rights Act 2015.

16.6 **Our liability to you.** If we fail to comply with these Terms, we are responsible for loss or damage you suffer that is a foreseeable result of our breach or our failure to use reasonable care and skill, but we are not responsible for loss or damage that is not foreseeable. We do not exclude or limit our liability where it would be unlawful to do so, including for death or personal injury caused by our negligence, for fraud, or for breach of your statutory rights. If you use the Services for any commercial or business purpose we have no liability to you for loss of profit, loss of business, business interruption or loss of business opportunity.

16.7 **Governing law and courts.** These Terms are governed by English law. You can bring legal proceedings in respect of the Services in the English courts. If you live in Scotland you can bring proceedings in either the Scottish or the English courts; if you live in Northern Ireland, in either the Northern Irish or the English courts. If you live outside the United Kingdom, you may also have the benefit of mandatory consumer protection laws of the country where you live.

16.8 **Complaints.** If you have a complaint, contact hello@support.getbloggable.com and we will try to resolve it. We are not a member of an alternative dispute resolution scheme and are not obliged to use one.

## 17. Limitation of liability (business customers)

17.1 Nothing in these Terms excludes or limits liability for: (a) death or personal injury caused by negligence; (b) fraud or fraudulent misrepresentation; (c) any liability that cannot be excluded or limited by law.

17.2 Subject to clause 17.1, we will not be liable to you, whether in contract, tort (including negligence), breach of statutory duty, misrepresentation or otherwise, for any: (a) loss of profit, revenue, business, contracts or anticipated savings; (b) loss of or damage to goodwill or reputation; (c) loss, corruption or inaccuracy of data or content, except to the extent caused by our breach of clause 14; (d) loss arising from Output you publish or rely on; (e) loss arising from a Third-Party Service, from your domain or DNS configuration, or from content or actions of your Members or readers; (f) costs of procuring substitute services; or (g) indirect, special or consequential loss, in each case even if foreseeable.

17.3 Subject to clauses 17.1 and 17.2, our total aggregate liability to you arising out of or in connection with the Terms and the Services in any 12-month period is limited to the greater of (a) the total fees you paid to us in the 12 months immediately before the event giving rise to the claim, and (b) £100.

17.4 You agree that the fees reflect this allocation of risk and that we would not provide the Services on these terms without it.

17.5 Any claim against us must be brought within 12 months of the date on which you became aware, or ought reasonably to have become aware, of the facts giving rise to it.

## 18. Your indemnity (business customers)

18.1 If you are a business customer, you will defend, indemnify and hold us and our officers, employees and contractors harmless from any claim, loss, liability, cost and expense (including reasonable legal fees) arising from: (a) Customer Content, including Output you publish; (b) your or your Members' breach of the Terms or the Acceptable Use Policy; (c) your use of a Third-Party Service; or (d) any allegation that content you supplied, imported or connected infringes a third party's rights or breaks the law.

18.2 We will notify you promptly of any claim, let you control its defence and settlement (provided that no settlement admits fault or imposes obligations on us without our consent), and give reasonable assistance at your cost.

## 19. Suspension, closure and termination

19.1 **Term.** These Terms apply from the moment you first accept them until your Account is closed.

19.2 **Closing your Account.** You may close your Account at any time from Settings, or by emailing hello@support.getbloggable.com. Closing your Account cancels any subscription under clause 5.8, unpublishes your blogs, and starts the deletion process in clause 19.5.

19.3 **Suspension.** We may suspend or lock all or part of your Account, immediately and without liability, where: (a) an amount you owe is overdue; (b) we reasonably believe you or a Member have breached the Terms or the Acceptable Use Policy; (c) your Account or content presents a security, legal or reputational risk to us, the Services or other customers; or (d) we are required to by law or by a court or regulator. We will tell you why, where the law allows, and lift the suspension once the issue is resolved.

19.4 **Termination.** Either of us may terminate the Terms: (a) if the other commits a material breach and, where it can be remedied, fails to remedy it within 14 days of being asked in writing; (b) if the other repeatedly breaches the Terms; (c) if the other becomes insolvent, enters administration or liquidation, or suffers anything equivalent. In addition, (d) we may terminate for convenience by giving you at least 60 days' notice, in which case we will refund any fees you have prepaid for the period after termination; and (e) we may terminate immediately if your Account has been on a free tier with no activity for 12 months, after giving you 30 days' notice by email.

19.5 **What happens on closure or termination.** Your right to use the Services ends. Your blogs are unpublished and custom domains disconnected. We keep your Customer Content for **30 days** so that you can ask us for an export, after which we delete it from our live systems, with copies in backups expiring on their normal rotation. We may keep records we need for accounting, tax, legal or security purposes for as long as the law requires. Any unused Credits are forfeited under clause 6.7. Where we terminate under clause 19.4(a) to (c), any fees due for the remainder of the current period remain payable.

19.6 **Survival.** Clauses that by their nature should survive termination do so, including clauses 6.6, 6.7, 7.7, 8.2, 12, 13, 14, 15, 16, 17, 18, 19.5, 19.6 and 21.

## 20. Changes to these Terms

20.1 We may change these Terms from time to time. Where a change is material, we will give you at least 30 days' notice by email to the Account owner and/or by a notice in the app before it takes effect. If you do not accept a material change you may cancel before it takes effect; continuing to use the Services after the effective date means you accept the change.

20.2 Changes that are required by law, that make the Terms clearer, or that add new features without reducing your rights may take effect immediately.

20.3 The current version, its effective date and previous versions are available at [/legal](/legal).

## 21. General

21.1 **Notices.** We will send notices to the email address of the Account owner; you must keep it current. You may send notices to us at hello@support.getbloggable.com or by post to our registered office. Email notices are treated as received when sent, unless a delivery failure is returned.

21.2 **Assignment.** You may not assign or transfer the Terms without our written consent. We may assign or transfer them to an affiliate or to a successor in connection with a merger, acquisition, reorganisation or sale of assets, provided your rights are not reduced.

21.3 **Subcontracting.** We may use subcontractors and sub-processors to provide the Services and remain responsible for them.

21.4 **Events outside our control.** Neither of us is liable for a failure or delay caused by events beyond our reasonable control, including failure of internet infrastructure, outages of Third-Party Services, power failure, industrial action, epidemic, or acts of government, provided the affected party notifies the other and uses reasonable efforts to mitigate. Payment obligations are not excused.

21.5 **Entire agreement.** These Terms are the entire agreement between us about the Services and supersede all earlier agreements and representations. Neither of us relies on any statement not set out in them, but nothing in this clause limits liability for fraud.

21.6 **Severance.** If any part of these Terms is found to be invalid or unenforceable, the rest continues in force and the invalid part is treated as modified to the minimum extent necessary to make it valid.

21.7 **Waiver.** A failure or delay in enforcing any right is not a waiver of it.

21.8 **No partnership.** Nothing in these Terms creates a partnership, joint venture, agency or employment relationship between us.

21.9 **Third parties.** No one other than you and us has any right to enforce any of these Terms under the Contracts (Rights of Third Parties) Act 1999.

21.10 **Governing law and jurisdiction.** These Terms, and any dispute or claim arising out of or in connection with them or their subject matter (including non-contractual disputes or claims), are governed by the law of England and Wales. Subject to clause 16.7, the courts of England and Wales have exclusive jurisdiction to settle any such dispute or claim.

21.11 **Language.** These Terms are written in English. Any translation is for convenience only and the English version prevails.

## 22. Contact us

- **Company:** Referr Ltd, trading as Bloggable
- **Registered in:** England and Wales, Company No. 14651607
- **Registered office:** 2nd Floor College House, 17 King Edwards Road, Ruislip, London, HA4 7AE, United Kingdom
- **Email:** hello@support.getbloggable.com


---

---
title: "Privacy Policy"
effective: 2026-09-05
version: "1.0"
source: "https://getbloggable.com/legal/privacy"
---

# Privacy Policy

Effective 5 September 2026 · Version 1.0

> **In plain English.** We collect what we need to run your account, bill you, generate content when you ask, keep the service secure and help you when something goes wrong. We do not sell personal data, we do not use your content to train AI models, and we do not run advertising trackers. Your content goes to our AI providers only to produce the result you asked for. You can access, correct, export or delete your data by contacting us. The detail is below.

## 1. Who we are

1.1 This Privacy Policy explains how **Referr Ltd**, trading as **Bloggable**, collects and uses personal data. We are the **controller** of the personal data described in this policy unless section 12 says otherwise. We are a company registered in England and Wales under number 14651607, with our registered office at 2nd Floor College House, 17 King Edwards Road, Ruislip, London, HA4 7AE, United Kingdom.

1.2 We pay the data protection fee to, and are registered with, the Information Commissioner's Office (ICO).

1.3 Questions about this policy or about your personal data should go to hello@support.getbloggable.com, or by post to the registered office above, marked "Privacy".

## 2. Who this policy covers

This policy applies to:

- **visitors** to our websites at getbloggable.com and bllog.io;
- **customers and their team members** who create or are invited to a Bloggable Account;
- **people who contact us**, join a waitlist, or go through our sign-up questionnaire;
- **readers of blogs that our customers publish** using Bloggable, in the limited way described in section 12; and
- **people whose personal data appears in our customers' content**, also described in section 12.

## 3. The personal data we collect

| Category | What it includes | Where it comes from |
|---|---|---|
| **Identity and contact** | Name, email address, profile image, job title, company name and website, country. | You, or your Google account when you sign in with Google. |
| **Account and workspace** | Your role, the Account you belong to, invitations you send or receive, settings, notification preferences, time zone, onboarding progress. | You, and the person who invited you. |
| **Billing** | Plan, subscription status, trial dates, invoices, currency, the identifier Stripe assigns to you, and the last four digits and expiry of your card as reported by Stripe. **We never receive or store full card numbers.** | You, via Stripe. |
| **Content** | Blogs, posts, drafts, revisions, images and media, writing samples used to learn your voice, brand guidelines, personas, reusable elements, competitor and content-source URLs, imported content from an existing blog. | You and your team. |
| **AI interaction data** | Instructions you give to AI features and to Joe, the content sent to generate a result, the result itself, scores, and the preferences Joe remembers (with personal data removed before storage). | You. |
| **Integration data** | Where you connect them: Google Search Console performance data for the sites you authorise; credentials for WordPress, Ghost or webhook destinations (stored encrypted); records of what was published where. | You, Google, and the services you connect. |
| **Support** | Support tickets, emails you send us, the Joe conversation you choose to attach to a ticket, and our replies. | You. |
| **Usage and technical** | IP address, browser and device type, pages and features used, sign-in times, error reports, rate-limit counters, and credit usage (an itemised ledger of every AI action and its cost). | Generated automatically when you use the Services. |
| **Website analytics** | Aggregated page-view statistics for our marketing site, collected without cookies using a daily-rotating hash rather than a persistent identifier. | Generated automatically. |
| **Leads and waitlists** | Answers to the sign-up questionnaire, your email address and name if you give them, and the campaign parameters in the link you arrived from. | You. |
| **Marketing preferences** | Whether you have opted out of product updates and other marketing email. | You. |

We do not deliberately collect special category data (such as health or political opinions) or data about criminal convictions, and we ask you not to include it in content you give to AI features or to support.

## 4. Why we use personal data, and our lawful basis

| Purpose | Lawful basis (UK GDPR Article 6) |
|---|---|
| Creating and running your Account, hosting your blogs, and providing every feature you use, including AI generation and Joe. | Performance of a contract with you (Art. 6(1)(b)). |
| Billing, collecting payment, preventing payment fraud, and keeping accounting records. | Contract (Art. 6(1)(b)) and legal obligation (Art. 6(1)(c)). |
| Sending service messages: sign-in links, invitations, receipts, renewal and trial reminders, low-credit warnings, publishing confirmations, and notices about changes to our terms. | Contract (Art. 6(1)(b)), and legal obligation where a notice is required by law. |
| Personalising Joe and content generation using preferences it remembers about how you like to work. | Legitimate interests (Art. 6(1)(f)): making the product more useful to you. You can ask Joe to forget any preference. |
| Keeping the Services secure: authentication, rate limiting, abuse and spam prevention, detecting attacks, investigating incidents. | Legitimate interests (Art. 6(1)(f)): protecting our customers, the Services and ourselves; and legal obligation where security measures are required by law. |
| Providing support and handling complaints. | Contract (Art. 6(1)(b)) and legitimate interests (Art. 6(1)(f)). |
| Understanding how the Services are used so that we can improve them, fix problems and plan capacity. | Legitimate interests (Art. 6(1)(f)). We use aggregated data wherever possible. |
| Sending product updates and marketing email to customers. | Legitimate interests (Art. 6(1)(f)), relying on the "soft opt-in" for existing customers, with an unsubscribe link in every message. |
| Following up with people who go through the sign-up questionnaire or join a waitlist. | Consent (Art. 6(1)(a)), which you give by submitting your details, and which you can withdraw at any time. |
| Complying with legal obligations, responding to lawful requests from authorities, and establishing, exercising or defending legal claims. | Legal obligation (Art. 6(1)(c)) and legitimate interests (Art. 6(1)(f)). |
| In connection with a merger, acquisition, financing or sale of our business. | Legitimate interests (Art. 6(1)(f)). |

Where we rely on legitimate interests, we have assessed that the processing is necessary and that our interests are not overridden by your rights. You can ask for a copy of that assessment or object to the processing (section 11).

## 5. How AI features use your data

5.1 When you use an AI feature, the content needed to produce the result, for example a topic brief, your writing samples, the post you are editing, or your message to Joe, is sent to our AI provider, **Anthropic**, through the **Vercel AI Gateway**, and the result is returned to you. Research features additionally send search queries derived from your topic to **Tavily**, a web search provider. No account identifiers are sent with those queries.

5.2 **Your content is not used to train AI models.** We do not train models on it and our providers are contractually prohibited from doing so. Providers may retain inputs and outputs for a short period for abuse monitoring and reliability, under contractual limits.

5.3 **Joe's memory.** Joe may record preferences about how you like to work (for example "prefers short paragraphs") to personalise future conversations and generation. Personal data such as names and email addresses is redacted before a preference is stored. Memory is scoped to your Account, and to you personally for communication preferences. You can ask Joe what it remembers and tell it to forget anything, or contact us.

5.4 **No solely automated decisions with legal effect.** AI features produce content and suggestions; they do not make decisions about you that have legal or similarly significant effects. Autopilot publishes content on your instructions and settings, not decisions about people.

5.5 **Please keep personal data out of prompts** unless you need it there. Content you publish becomes public (section 12).

## 6. Who we share personal data with

6.1 **Sub-processors.** We use the following providers to run the Services. Each acts on our instructions under a written contract that meets the requirements of UK GDPR Article 28. The current list is also published on our [Trust Centre](/trust), where we announce additions.

| Sub-processor | Purpose | Personal data | Location | Transfer safeguard |
|---|---|---|---|---|
| **Vercel** (Vercel Inc.) | Application hosting and serverless compute, global edge network, file storage for uploaded media (Vercel Blob), cookieless web analytics, and the AI Gateway that routes our model requests. | All service data in transit and at rest on the platform; uploaded media; request logs (IP address, user agent). | Ireland (Dublin region); cached public content served from a global edge network | UK adequacy regulations (EEA); UK Extension to the EU–US Data Privacy Framework or the UK Addendum to the EU SCCs for any access from the United States |
| **MongoDB Atlas** (MongoDB, Inc.) | Managed primary database. | All account, content, billing-metadata, support and usage records. | Ireland (Dublin region) | UK adequacy regulations (EEA); UK Extension to the EU–US Data Privacy Framework or the UK Addendum to the EU SCCs for any access from the United States |
| **Anthropic** (Anthropic, PBC) | Large language model inference (Claude) for research synthesis, drafting, editing, scoring, repurposing and the Joe assistant. Accessed through the Vercel AI Gateway. | Prompts and content submitted for generation — post text, voice samples, brief and topic details, Joe conversations (with personal data redacted from stored memory). Not used to train models. | United States | UK Extension to the EU–US Data Privacy Framework, or the UK Addendum to the EU SCCs |
| **Tavily** (Tavily, Inc.) | Web research search API used by the research and competitor pipelines. | Search queries derived from the topic, keywords and competitor URLs a customer supplies. No account identifiers. | United States | UK Addendum to the EU SCCs / IDTA |
| **Stripe** (Stripe Payments UK Ltd and Stripe, Inc.) | Payments, subscription billing, invoicing, the customer billing portal and payment fraud prevention. | Name, email address, billing address, payment card details (entered directly with Stripe and never seen by Bloggable), transaction history. | United Kingdom, European Union and United States | UK Extension to the EU–US Data Privacy Framework, or the UK Addendum to the EU SCCs |
| **Resend** (Resend, Inc.) | Delivery of transactional, notification and product-update email; receipt of inbound support email. | Name, email address, message subject and content, delivery events (sent, bounced). | United States | UK Addendum to the EU SCCs / IDTA |
| **Google** (Google LLC) | Sign in with Google (OAuth); and, only for customers who connect it, the Google Search Console API for search performance data. | Google account email, name and profile image at sign-in; Search Console performance data for the sites a customer authorises. | United States | UK Extension to the EU–US Data Privacy Framework, or the UK Addendum to the EU SCCs |
| **Unsplash** (Unsplash, Inc.) | Stock photography search and download for featured images. | Image search terms only. No account identifiers or personal data. | Canada | UK adequacy regulations (Canada) |

6.2 **Your team.** Members of your Account can see the Account's content and settings according to their role. The Account owner and admins can see who is in the Account and what has been published.

6.3 **Services you connect.** If you connect Google Search Console, WordPress, Ghost or a webhook, we send data to that service on your instruction. Those services are not our sub-processors; they are yours, and their privacy policies apply.

6.4 **The public.** Content you publish, including the author name or persona you attach to it, is public.

6.5 **Professional advisers, authorities and successors.** We may share personal data with our lawyers, accountants, auditors and insurers; with courts, regulators and law enforcement where the law requires or permits it; and with a buyer or successor of our business, who must honour this policy.

6.6 **We do not sell personal data**, and we do not share it with advertising networks or data brokers.

## 7. International transfers

7.1 We are based in the United Kingdom. Our application and database are hosted in Ireland. Some of our other providers process data in the United States and, for content delivery, at edge locations around the world. Where personal data leaves the UK we make sure it is protected by one of the safeguards recognised by UK law: the provider's certification under the UK Extension to the EU–US Data Privacy Framework; the International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses issued by the ICO; or transfer to a country that the UK has found to provide adequate protection. Details for each provider are in the table in section 6, and you can ask us for a copy of the relevant safeguard.

## 8. How long we keep personal data

| Data | Retention |
|---|---|
| Account, profile and settings | While your Account is open, then deleted within 30 days of closure (section 9 of the Terms), except for records we must keep for legal reasons. |
| Content, media and AI-generated material | While your Account is open, then 30 days after closure so you can request an export, then deleted from live systems. Backup copies expire on their normal rotation. |
| Joe conversations | Automatically deleted 90 days after the last message in the conversation. A conversation you attach to a support ticket is kept with the ticket. |
| Joe memory (preferences) | Until you ask Joe or us to forget it, or your Account is closed. |
| Credit ledger and billing records | 6 years after the end of the financial year they relate to, as required by UK tax and company law. |
| Support tickets and emails | Up to 6 years after the ticket is closed, as a business record and to defend legal claims. |
| Email delivery queue | 30 days after the email is sent. |
| System and job logs | Up to 90 days. |
| Rate-limit and abuse counters | Between one minute and 24 hours, depending on the limit. |
| Visitor hashes used to count unique readers of blogs | 24 hours. The aggregate daily counts that remain contain no personal data. |
| Sign-up questionnaire answers | 180 days if you do not create an Account, otherwise as part of your Account. |
| Waitlist entries | Until the waitlist closes or you ask to be removed. |
| Marketing opt-outs | Indefinitely, so that we continue to honour them. |

## 9. Security

9.1 We protect personal data with measures that include encryption in transit (TLS) and at rest, application-level encryption of integration credentials, role-based access control enforced on every request, tenant isolation of every Account's data, rate limiting, content sanitisation, and logging of administrative actions. Payment card details are handled entirely by Stripe. Our security programme is described in more detail on our [Trust Centre](/trust).

9.2 No system is perfectly secure. If we become aware of a personal data breach that is likely to result in a risk to you, we will notify you and, where required, the ICO without undue delay.

## 10. Your rights

10.1 Under UK data protection law you have the right to:

- **access** the personal data we hold about you and receive a copy;
- **rectify** inaccurate or incomplete data;
- **erase** your data in certain circumstances, for example where it is no longer needed;
- **restrict** processing in certain circumstances;
- **data portability**: receive data you gave us in a structured, machine-readable format, where processing is based on contract or consent and is automated;
- **object** to processing based on legitimate interests, and to direct marketing at any time;
- **withdraw consent** at any time where consent is the basis for processing, without affecting processing already carried out; and
- **not be subject to a decision based solely on automated processing** that produces legal or similarly significant effects.

10.2 You can update most of your details and preferences in Settings, and export your content from the app. For anything else, email hello@support.getbloggable.com. We may need to confirm your identity. We will respond within one month, or tell you if we need longer for a complex request. We do not charge for requests unless they are manifestly unfounded or excessive.

10.3 You have the right to complain to the ICO at [ico.org.uk/make-a-complaint](https://ico.org.uk/make-a-complaint/) or on 0303 123 1113. We would appreciate the chance to resolve your concern first.

## 11. Marketing and communications

11.1 **Service messages** (sign-in links, receipts, renewal reminders, security notices, and notices about changes to our terms) are part of running your Account. You can turn off optional notifications, such as the monthly digest and Autopilot activity, in Settings, but you cannot opt out of messages we are required to send.

11.2 **Product updates and marketing email** go to customers under the soft opt-in. Every such email contains an unsubscribe link, and you can also opt out in Settings → Notifications. We will honour an opt-out within a few days.

11.3 If you gave us your email through the sign-up questionnaire or a waitlist, we will contact you about that subject. You can withdraw at any time using the link in the email or by contacting us.

## 12. Readers of our customers' blogs, and personal data in customer content

12.1 Blogs published with Bloggable belong to our customers. For the data of their readers, and for any personal data in the content they publish, **the customer is the controller and we are a processor** acting under our [Data Processing Addendum](/legal/dpa). If you have a question or a rights request about a blog, please contact its owner; if you cannot reach them, contact us and we will pass your request on.

12.2 When you read a blog hosted by us, we process the following on the customer's behalf:

- **Server logs** held by our hosting provider, including your IP address, browser type and the page requested, for security and reliability.
- **Reader counts**: a first-party beacon records that a page was viewed. To count unique daily readers without cookies, we create a hash of your IP address, browser identifier and the date. The hash cannot be reversed, is not linked to any profile, and is discarded after 24 hours. No cookies or persistent identifiers are set by us on a customer's blog.
- **Embedded content** such as video, audio or social-media posts that a customer places in an article is loaded from the third-party platform, which may set its own cookies. The customer is responsible for any notice or consent that requires.

12.3 A **persona** shown as the author of a post may not be a real person. Where a customer attributes content to a real named person, the customer is responsible for that person's data.

## 13. Cookies

13.1 We use only cookies that are strictly necessary to sign you in and keep the Services secure, plus a cookie that records your response to our cookie notice. Our analytics do not use cookies. See our [Cookie Policy](/legal/cookies) for the full list.

## 14. Children

14.1 The Services are not directed at, and may not be used by, anyone under 18. We do not knowingly collect personal data from children. If you believe a child has given us personal data, contact us and we will delete it.

## 15. Links to other sites

15.1 Our websites and our customers' blogs may link to sites we do not control. Their privacy policies, not ours, apply there.

## 16. Google user data

16.1 If you sign in with Google, we receive your Google account email address, name and profile image, and use them to create and identify your Bloggable login.

16.2 If you connect **Google Search Console**, we request read-only access to Search Console data for the properties you choose and use it to show search performance, detect declining pages and suggest content to refresh, inside your Account. We store the access token encrypted and delete it when you disconnect. Bloggable's use and transfer to any other app of information received from Google APIs will adhere to the [Google API Services User Data Policy](https://developers.google.com/terms/api-services-user-data-policy), including the Limited Use requirements. In particular, we do not use Google user data for advertising, we do not sell it, and we do not allow humans to read it except with your consent, for security purposes, to comply with the law, or in aggregated form for internal operations. You can revoke our access at any time from Settings → Integrations or at [myaccount.google.com/permissions](https://myaccount.google.com/permissions).

## 17. Changes to this policy

17.1 We will update this policy when our processing changes. Material changes will be notified by email to Account owners or by a notice in the app before they take effect. The effective date and version are shown at the top of this page, and previous versions are available on request.

## 18. Contact

- **Controller:** Referr Ltd, trading as Bloggable
- **Address:** 2nd Floor College House, 17 King Edwards Road, Ruislip, London, HA4 7AE, United Kingdom
- **Email:** hello@support.getbloggable.com


---

---
title: "Acceptable Use Policy"
effective: 2026-09-05
version: "1.0"
source: "https://getbloggable.com/legal/acceptable-use"
---

# Acceptable Use Policy

Effective 5 September 2026 · Version 1.0

> **In plain English.** Publish what you like as long as it is lawful, honest and yours to publish. Do not use Bloggable to deceive people, to infringe other people's work, to flood the web with junk, or to attack anyone. If you see something on a Bloggable-hosted blog that breaks these rules, tell us and we will act.

## 1. Purpose and scope

1.1 This Acceptable Use Policy (the **"Policy"**) forms part of the [Terms of Service](/legal/terms) between you and Referr Ltd, trading as Bloggable. Capitalised words have the meaning given in the Terms.

1.2 The Policy applies to everything you and your Members do with the Services and to everything you publish or distribute through them, whether written by a person, generated by an AI feature, imported from elsewhere, or published automatically by Autopilot. You are responsible for content published under your Account regardless of how it was produced.

## 2. Prohibited content

You must not upload, generate, publish or distribute content that:

2.1 is **unlawful** in the United Kingdom or in any country you direct it to, or encourages or assists unlawful acts;

2.2 **infringes** anyone's copyright, database right, trade mark, design right, patent, trade secret, right of confidence, privacy rights or other rights, including by reproducing substantial parts of articles, images or other works you do not have the right to use;

2.3 is **defamatory**, or is a malicious falsehood about a person or organisation;

2.4 is **threatening, abusive or harassing**, incites hatred or violence against any person or group, or is discriminatory on the basis of a protected characteristic under the Equality Act 2010;

2.5 **sexualises children**, or depicts or facilitates the abuse of children in any way. We report such material to the relevant authorities;

2.6 is **pornographic** or sexually explicit;

2.7 promotes **terrorism**, extremist violence, self-harm, suicide or eating disorders, or gives instructions for making weapons, explosives or harmful substances;

2.8 contains **malware**, or links to it, or is designed for phishing, credential theft, or any other attack on people, devices or networks;

2.9 is **deceptive**: content that impersonates a person, organisation or brand; that misrepresents who wrote it, who is behind it, or its commercial purpose; fake or incentivised reviews or testimonials; or any practice prohibited by the Consumer Protection from Unfair Trading Regulations 2008 or the Digital Markets, Competition and Consumers Act 2024;

2.10 breaches **advertising or sector rules** that apply to you, including the UK Advertising Codes, financial promotion rules, rules on medical, health or nutrition claims, gambling advertising rules, or rules on promoting alcohol, tobacco, vaping or age-restricted products to people who should not receive it;

2.11 discloses another person's **private information** (such as an address, identity documents, financial details or health information) without their consent;

2.12 is **spam**: bulk, unsolicited, repetitive or machine-generated content whose purpose is to manipulate search engines or AI systems rather than to inform readers, including doorway pages, cloaking, keyword stuffing, scraped or spun content, and networks of near-duplicate sites; or

2.13 we reasonably consider to be harmful to the Services, to other customers, to Bloggable's reputation, or to the reputation of the domains on which we host customer content.

## 3. Prohibited conduct

You must not:

3.1 use the Services to send unsolicited email or messages, or to publish content that instructs others to do so;

3.2 attempt to gain unauthorised access to any Account, system, network or data, or probe, scan or test the vulnerability of the Services without our written permission (see our [Trust Centre](/trust) for responsible disclosure);

3.3 interfere with the operation of the Services, impose an unreasonable load on them, or circumvent rate limits, credit accounting, plan limits, trial restrictions or any other control;

3.4 create multiple Accounts, or use multiple payment methods, to obtain more than one free trial or promotional benefit;

3.5 share your sign-in with people outside your Account, or allow your Account to be used to provide the Services to others as a service bureau, except that agencies may operate blogs for their clients within the limits of their Plan;

3.6 scrape, harvest or bulk-download content or data from the Services or from other customers' blogs other than through the feeds, sitemaps and Markdown files they publish and in accordance with their robots rules;

3.7 use the Services to build a competing product, or to create datasets for training machine-learning models;

3.8 add a website as a content source or competitor unless you have the right to access and analyse it and doing so does not breach its terms;

3.9 connect a domain, integration or third-party account that you do not own or are not authorised to use; or

3.10 misrepresent your identity or affiliation when dealing with us or our support staff.

## 4. Rules for AI-generated content and automation

4.1 **You are the publisher.** AI features assist you; they do not replace your judgement. Review AI output for accuracy, originality and compliance before it is published, or set Autopilot's quality thresholds, volume and budget with that responsibility in mind.

4.2 **No deception about people.** Do not use personas or AI features to invent experts, testimonials, reviews, case studies, credentials, or first-hand experiences that did not happen. A persona is an editorial voice, not evidence.

4.3 **No content farms.** Do not use the Services to mass-produce low-value content whose purpose is to attract traffic or manipulate rankings rather than to inform readers. Autopilot exists to publish content you would be willing to put your name to; volume that outruns your ability to stand behind it is a breach of this Policy.

4.4 **Regulated subjects.** If you publish on health, finance, law, safety or other subjects where inaccurate information can cause harm, you must have the competence to check what is published, and you must comply with the rules of the sector.

4.5 **Prohibited generation.** You must not use AI features to attempt to generate content listed in section 2, to circumvent the safety behaviour of the models, or to extract our prompts, system instructions or other confidential aspects of the Services.

4.6 **Research features** cite public web sources. You must not use them to reproduce substantial parts of a third party's work, to circumvent paywalls, or to target a website you are not permitted to access.

## 5. Blog addresses, handles and domains

5.1 You must not register or use a blog address, premium handle or custom domain that infringes a trade mark, impersonates a person or organisation, is misleading, or is offensive. We may withdraw or reassign such addresses.

5.2 Do not hoard addresses or handles for the purpose of resale.

## 6. Fair use

6.1 Plan limits, Credit costs, storage limits and rate limits are enforced automatically. We may also apply a fair-use judgement where usage is far outside what is normal for a Plan and is affecting other customers, and we will tell you if we do.

## 7. Reporting infringement or unlawful content (notice and takedown)

7.1 If you believe content on a blog hosted by Bloggable infringes your rights or is unlawful, email hello@support.getbloggable.com with "Takedown" in the subject line, or write to us at 2nd Floor College House, 17 King Edwards Road, Ruislip, London, HA4 7AE, United Kingdom, and include:

- your name, organisation (if any) and contact details;
- the exact URL(s) of the content;
- a description of the right you say is infringed, or of why the content is unlawful, and, for copyright, identification of the work and evidence that you own it or act for the owner;
- a statement that you believe in good faith that the use is not authorised and that the information you have given is accurate; and
- for copyright and trade mark complaints, a statement that you are, or are authorised to act for, the rights holder.

7.2 We will acknowledge a complete notice within 2 business days and will normally decide within 5 business days whether to remove or disable access to the content. Where the content is plainly unlawful or dangerous we act immediately. We may pass your notice, without your contact details unless the law requires them, to the customer.

7.3 **Counter-notice.** A customer whose content is removed may send us a counter-notice explaining why the content is lawful or why they hold the necessary rights. Where the counter-notice is credible and the complainant does not tell us within 10 business days that they have started legal proceedings, we may restore the content. We are not obliged to adjudicate disputes between you and a third party.

7.4 **Repeat infringers.** We close the Accounts of customers who repeatedly publish infringing or unlawful content.

7.5 **Other abuse.** To report spam, malware, harassment, impersonation or any other breach of this Policy, email hello@support.getbloggable.com with "Abuse" in the subject line and the URL concerned.

## 8. Enforcement

8.1 If we reasonably believe that this Policy has been breached we may, depending on the seriousness: warn you; require you to change or remove content; remove, unpublish or disable content, a blog, an address or an integration; pause Autopilot; suspend or lock your Account; or terminate the Terms. Credits and fees are not refunded where we act under this section.

8.2 Where practicable we will tell you what we have done and why, and give you the chance to put it right. We may not do so where telling you would prejudice an investigation, where the law prevents it, or where the breach is serious.

8.3 We may report content or conduct to law enforcement, regulators or other authorities where we believe it is appropriate, and we cooperate with lawful requests from them.

## 9. Comments, communities and the Online Safety Act 2023

9.1 Blogs hosted by Bloggable do not include comment, forum or messaging features, and Bloggable is not designed to enable readers to interact with each other. If you add such features to your blog through embedded third-party services, you are responsible for them, including for any duties that apply to you under the Online Safety Act 2023.

## 10. Changes

10.1 We may update this Policy under clause 20 of the Terms. The effective date and version are shown at the top of this page.

## 11. Contact

- **Abuse and takedown notices:** hello@support.getbloggable.com
- **By post:** Referr Ltd, trading as Bloggable, 2nd Floor College House, 17 King Edwards Road, Ruislip, London, HA4 7AE, United Kingdom


---

---
title: "Cookie Policy"
effective: 2026-09-05
version: "1.0"
source: "https://getbloggable.com/legal/cookies"
---

# Cookie Policy

Effective 5 September 2026 · Version 1.0

> **In plain English.** We set only the cookies needed to keep you signed in and to protect your session, plus one that remembers you have seen the cookie notice. Our analytics do not use cookies. Blogs published by our customers do not receive cookies from us at all.

## 1. About this policy

1.1 This policy explains how Referr Ltd, trading as Bloggable, uses cookies and similar technologies on getbloggable.com and bllog.io, and on blogs we host for our customers. It should be read with our [Privacy Policy](/legal/privacy).

1.2 A **cookie** is a small text file that a website stores on your device. **Local storage** is a similar mechanism that stores data in your browser without sending it to the server on every request. The Privacy and Electronic Communications (EC Directive) Regulations 2003 require us to tell you about them and to obtain your consent for any that are not strictly necessary.

## 2. Cookies we set on our own sites

| Name | Purpose | Type | Duration |
|---|---|---|---|
| next-auth.session-token (or __Secure-next-auth.session-token) | Keeps you signed in. Contains a signed token identifying your login; it does not contain your password. | Strictly necessary | 30 days, refreshed while you use the app |
| next-auth.csrf-token (or __Host-next-auth.csrf-token) | Protects sign-in and sign-out requests against cross-site request forgery. | Strictly necessary | Session |
| next-auth.callback-url | Remembers the page to return you to after signing in. | Strictly necessary | Session |
| cookieConsent | Records that you have acknowledged our cookie notice so it is not shown again. | Preference | Persistent |

These cookies are set by us (first-party). We do not use them to track you across other websites.

## 3. Browser storage

We use local storage in the Bloggable app for interface state such as which blog you last had selected, unsaved editor changes, collapsed panels and dismissed tips. This data stays in your browser, is not used for tracking, and is cleared when you clear your browser's site data.

## 4. Analytics

We measure visits to our marketing site using Vercel Web Analytics, which **does not use cookies** or any persistent identifier. It derives a hash from your IP address and browser that changes every day and cannot be linked back to you, and we only ever see aggregated page-view counts. Inside the app we record which features are used against your Account, as described in the Privacy Policy, without third-party tracking scripts.

## 5. Third-party services you may be sent to

5.1 **Stripe.** When you subscribe or manage billing you are taken to pages hosted by Stripe, which sets its own cookies for fraud prevention and to operate its checkout. See [Stripe's cookie policy](https://stripe.com/gb/legal/cookies-policy).

5.2 **Google.** If you sign in with Google, or connect Google Search Console, Google's pages set Google's cookies. See [Google's policy](https://policies.google.com/technologies/cookies).

We do not load Stripe's or Google's scripts on pages that do not need them.

## 6. Blogs published by our customers

6.1 Bloggable sets **no cookies** and no local storage on the blogs it hosts for customers, whether at a path on getbloggable.com, a handle on bllog.io, or a custom domain. Reader counts use a first-party beacon with a daily-rotating hash rather than an identifier (see section 12 of the Privacy Policy).

6.2 Content that a customer embeds from third-party platforms, such as YouTube, Vimeo, Spotify, SoundCloud, CodePen or X, is loaded from that platform when the page is viewed and may set that platform's cookies. The blog owner, as the controller of their site, is responsible for any notice or consent that requires. A blog owner can avoid this by not embedding third-party content.

## 7. Managing cookies

7.1 Because we set no cookies that require consent, the notice shown on our site is informational; choosing "Decline" does not affect how the site works, and no non-essential cookies are set either way.

7.2 You can block or delete cookies in your browser settings. If you block the strictly necessary cookies you will not be able to sign in. Instructions for common browsers are at [allaboutcookies.org](https://allaboutcookies.org/).

## 8. Changes

8.1 If we introduce cookies that require consent we will update this policy, update the notice on our site to ask for consent before they are set, and give you a way to withdraw it.

## 9. Contact

Questions about cookies: hello@support.getbloggable.com


---

---
title: "Data Processing Addendum"
effective: 2026-09-05
version: "1.0"
source: "https://getbloggable.com/legal/dpa"
---

# Data Processing Addendum

Effective 5 September 2026 · Version 1.0

> **In plain English.** Where your blog's readers, or people mentioned in your content, are concerned, you are the data controller and we process data for you. This document is the contract UK data protection law requires for that: we only act on your instructions, keep the data secure, tell you if something goes wrong, help you with your obligations, use only the sub-processors listed and delete the data when you leave. It applies automatically; no signature is needed.

## 1. Background and application

1.1 This Data Processing Addendum (**"DPA"**) forms part of the [Terms of Service](/legal/terms) (the **"Terms"**) between **Referr Ltd**, trading as **Bloggable** (**"Processor"**, **"we"**, **"us"**), and the customer that holds the Account (**"Controller"**, **"you"**).

1.2 This DPA applies to the extent we process **Customer Personal Data** (defined below) on your behalf in providing the Services. It does not apply to personal data of which we are the controller, such as your own account, billing and usage data, which is governed by our [Privacy Policy](/legal/privacy).

1.3 This DPA is incorporated by reference and takes effect on the date you accept the Terms. A countersigned copy is available on request from hello@support.getbloggable.com.

## 2. Definitions

2.1 **"Data Protection Law"** means the UK GDPR, the Data Protection Act 2018, and the Privacy and Electronic Communications (EC Directive) Regulations 2003, each as amended, and, where applicable to the Controller, the EU GDPR.

2.2 **"Customer Personal Data"** means personal data that we process on your behalf in providing the Services, as described in Annex 1, including personal data contained in Customer Content and data about readers of your blogs.

2.3 **"Sub-processor"** means a third party engaged by us to process Customer Personal Data.

2.4 **"controller"**, **"processor"**, **"data subject"**, **"personal data"**, **"personal data breach"** and **"processing"** have the meanings given in Data Protection Law. Other capitalised terms have the meanings given in the Terms.

## 3. Roles and instructions

3.1 You are the controller (or, where you act for a client, a processor authorised by the controller) of Customer Personal Data, and we are your processor.

3.2 We will process Customer Personal Data only on your documented instructions, including with regard to transfers to a third country, unless we are required to do so by law, in which case we will inform you of that requirement before processing unless the law prohibits it on important grounds of public interest.

3.3 Your instructions are: (a) the Terms and this DPA; (b) your use of the Services and their settings, including publishing content, enabling Autopilot, connecting integrations and running AI features; and (c) any further reasonable written instruction consistent with the Terms. We will tell you if, in our opinion, an instruction infringes Data Protection Law, without any obligation to review your instructions for compliance.

3.4 You are responsible for: the lawfulness of Customer Personal Data and of your instructions; providing any notice and obtaining any consent required from data subjects, including readers of your blogs; responding to data subjects' requests; and ensuring that you are entitled to appoint us as processor, including where you act for a client.

## 4. Our obligations

4.1 **Confidentiality.** We will ensure that persons authorised to process Customer Personal Data are bound by obligations of confidentiality and receive appropriate training.

4.2 **Security.** We will implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing. Our current measures are summarised in Annex 2 and described in more detail on our [Trust Centre](/trust). We may update them provided the overall level of security is not reduced.

4.3 **Sub-processors.** You give general authorisation for us to engage the Sub-processors listed in Annex 3. We will impose data protection obligations on each Sub-processor that are no less protective than those in this DPA, and we remain liable to you for their performance. We will give you at least **30 days' notice** of any intended addition or replacement of a Sub-processor by publishing it on the [Trust Centre](/trust) and, for material changes, by email to the Account owner. You may object on reasonable data protection grounds within that period; if we cannot address your objection, you may terminate the affected part of the Services under the Terms, and we will refund any prepaid fees for the unused period.

4.4 **Data subject rights.** Taking into account the nature of the processing, we will assist you by appropriate technical and organisational measures, so far as possible, in responding to requests from data subjects to exercise their rights. If a data subject contacts us directly about Customer Personal Data we will, where we can identify you, pass the request to you without responding on your behalf unless you instruct us to.

4.5 **Assistance.** We will assist you, taking into account the nature of the processing and the information available to us, in meeting your obligations regarding security, personal data breach notification, data protection impact assessments and prior consultation with the ICO.

4.6 **Deletion and return.** On closure or termination of your Account, we will delete Customer Personal Data in accordance with clause 19.5 of the Terms: content remains available for export for 30 days, after which it is deleted from live systems, with backup copies expiring on their normal rotation, unless the law requires us to retain it. During the term you can export published content in Markdown from its URL and export content from the app.

4.7 **Information and audit.** We will make available to you the information necessary to demonstrate compliance with this DPA, and allow for and contribute to audits, including inspections, conducted by you or an auditor mandated by you, on the following basis: (a) you first request our written responses and any third-party reports we hold, which will satisfy the audit right unless a supervisory authority requires more or you have reasonable grounds to suspect non-compliance; (b) any on-site audit is limited to once in any 12-month period, on at least 30 days' written notice, during business hours, subject to reasonable confidentiality and security requirements, and at your cost; and (c) audits do not extend to the systems of our Sub-processors, in respect of which we will provide the information they make available to us.

## 5. Personal data breach

5.1 We will notify you **without undue delay, and in any event within 72 hours, after becoming aware** of a personal data breach affecting Customer Personal Data. The notice will describe, so far as known, the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a point of contact. We may provide the information in phases as it becomes available.

5.2 We will cooperate with you and take reasonable steps to contain, investigate and remediate the breach. We will not notify data subjects or authorities on your behalf unless you instruct us to or the law requires it.

## 6. International transfers

6.1 We may process Customer Personal Data outside the United Kingdom through the Sub-processors listed in Annex 3. Where we do so, we ensure that the transfer is covered by: adequacy regulations under the UK GDPR; the International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses issued by the ICO; the recipient's certification under the UK Extension to the EU–US Data Privacy Framework; or another valid transfer mechanism. Copies of the relevant safeguards are available on request.

## 7. Liability

7.1 Each party's liability under this DPA is subject to the exclusions and limitations in the Terms, which apply to this DPA as if set out in full. Nothing in this DPA limits either party's liability to a data subject or supervisory authority under Data Protection Law.

## 8. Term and precedence

8.1 This DPA lasts for as long as we process Customer Personal Data. Clause 4.6 survives termination.

8.2 In the event of conflict between this DPA and the Terms regarding the processing of Customer Personal Data, this DPA prevails.

8.3 This DPA is governed by the law of England and Wales in accordance with clause 21.10 of the Terms.

## Annex 1 — Details of processing

**Subject matter.** Provision of the Services described in the Terms: hosting and publishing blogs, generating and editing content with AI, monitoring performance, repurposing content, and integrating with services you connect.

**Duration.** For as long as you hold an Account, plus the deletion period in clause 4.6.

**Nature and purpose.** Storage, hosting, retrieval, transmission, display, analysis, transformation and, on your instruction, publication of Customer Content; collection of aggregate reader statistics; transmission of content to AI providers to generate results; transmission of content to third-party destinations you connect; and deletion.

**Categories of data subjects.**

- Readers and visitors of your blogs.
- Individuals whose personal data appears in your content: authors, contributors, interviewees, people quoted or referred to, and personas where they correspond to real people.
- Your clients and their staff, where you operate blogs for clients.
- Individuals whose data appears in websites you add as content sources or competitors, to the extent captured in analyses.

**Categories of personal data.**

- For readers: IP address, browser identifier and requested page in transient server logs; a daily-rotating, irreversible hash used for unique-reader counts.
- In content: names, images, roles, biographical details, opinions, contact details and any other personal data you choose to include.
- In integration data: names and addresses of authors and sites on the destinations you connect.

**Special category data.** None intended. You must not include special category data or criminal-offence data in content submitted to AI features, and should avoid publishing it.

## Annex 2 — Technical and organisational measures

A summary of the measures in place at the effective date. The [Trust Centre](/trust) carries the current detail.

- **Encryption in transit** using TLS for all connections, with HTTP Strict Transport Security preloaded on our domains.
- **Encryption at rest** for the database and file storage, managed by our infrastructure providers, plus application-level encryption of integration credentials.
- **Access control**: authentication by Google OAuth or emailed sign-in links (no passwords stored); role-based permissions enforced server-side on every request; every database query scoped to the Account; staff access to the administration console restricted to named personnel and re-verified on each request.
- **Tenant isolation** of content, settings, AI memory and integration credentials by Account and by blog.
- **Application security**: server-side sanitisation of customer-authored content; browser security headers; restricted outbound fetching; rate limiting on public and sensitive endpoints; signed tokens on links in email; authenticated scheduled jobs.
- **AI safeguards**: web content treated as untrusted data in prompts; personal data redacted from stored assistant memory; server-side verification of confirmations for destructive actions; no use of Customer Personal Data to train models.
- **Payment data** never touches our systems; Stripe, a PCI DSS Level 1 service provider, handles it.
- **Logging and audit**: append-only credit ledger, job logs and administrative action records.
- **Availability**: managed, replicated database with automated backups; globally distributed serverless hosting; caching of public content.
- **Personnel**: confidentiality obligations and least-privilege access for anyone with access to production systems.
- **Incident response**: documented process for containment, investigation, notification under clause 5, and post-incident review.

## Annex 3 — Sub-processors

Authorised Sub-processors at the effective date. The live list, with the date each was added, is at [/trust](/trust#sub-processors).

| Sub-processor | Purpose | Personal data | Location | Transfer safeguard |
|---|---|---|---|---|
| **Vercel** (Vercel Inc.) | Application hosting and serverless compute, global edge network, file storage for uploaded media (Vercel Blob), cookieless web analytics, and the AI Gateway that routes our model requests. | All service data in transit and at rest on the platform; uploaded media; request logs (IP address, user agent). | Ireland (Dublin region); cached public content served from a global edge network | UK adequacy regulations (EEA); UK Extension to the EU–US Data Privacy Framework or the UK Addendum to the EU SCCs for any access from the United States |
| **MongoDB Atlas** (MongoDB, Inc.) | Managed primary database. | All account, content, billing-metadata, support and usage records. | Ireland (Dublin region) | UK adequacy regulations (EEA); UK Extension to the EU–US Data Privacy Framework or the UK Addendum to the EU SCCs for any access from the United States |
| **Anthropic** (Anthropic, PBC) | Large language model inference (Claude) for research synthesis, drafting, editing, scoring, repurposing and the Joe assistant. Accessed through the Vercel AI Gateway. | Prompts and content submitted for generation — post text, voice samples, brief and topic details, Joe conversations (with personal data redacted from stored memory). Not used to train models. | United States | UK Extension to the EU–US Data Privacy Framework, or the UK Addendum to the EU SCCs |
| **Tavily** (Tavily, Inc.) | Web research search API used by the research and competitor pipelines. | Search queries derived from the topic, keywords and competitor URLs a customer supplies. No account identifiers. | United States | UK Addendum to the EU SCCs / IDTA |
| **Stripe** (Stripe Payments UK Ltd and Stripe, Inc.) | Payments, subscription billing, invoicing, the customer billing portal and payment fraud prevention. | Name, email address, billing address, payment card details (entered directly with Stripe and never seen by Bloggable), transaction history. | United Kingdom, European Union and United States | UK Extension to the EU–US Data Privacy Framework, or the UK Addendum to the EU SCCs |
| **Resend** (Resend, Inc.) | Delivery of transactional, notification and product-update email; receipt of inbound support email. | Name, email address, message subject and content, delivery events (sent, bounced). | United States | UK Addendum to the EU SCCs / IDTA |
| **Google** (Google LLC) | Sign in with Google (OAuth); and, only for customers who connect it, the Google Search Console API for search performance data. | Google account email, name and profile image at sign-in; Search Console performance data for the sites a customer authorises. | United States | UK Extension to the EU–US Data Privacy Framework, or the UK Addendum to the EU SCCs |
| **Unsplash** (Unsplash, Inc.) | Stock photography search and download for featured images. | Image search terms only. No account identifiers or personal data. | Canada | UK adequacy regulations (Canada) |

## Contact

- **Processor:** Referr Ltd, trading as Bloggable
- **Address:** 2nd Floor College House, 17 King Edwards Road, Ruislip, London, HA4 7AE, United Kingdom
- **Data protection enquiries:** hello@support.getbloggable.com


---

# Trust Centre

> Security controls, compliance, sub-processors, data location and vulnerability disclosure for Bloggable. Last updated 2026-09-07.

## Compliance

- **UK GDPR / Data Protection Act 2018** — Privacy Policy, Data Processing Addendum, sub-processor list and rights process published.
- **PECR (cookies and marketing)** — Strictly necessary cookies only; cookieless analytics; unsubscribe on every marketing email.
- **PCI DSS** — Card processing is performed by Stripe, a PCI DSS Level 1 service provider. We do not store card data.
- **Infrastructure certifications** — Our hosting provider (Vercel) and database provider (MongoDB Atlas) hold SOC 2 Type II and ISO/IEC 27001 certifications. Their reports are available from the providers.
- **International transfers** — Transfers out of the UK rely on UK adequacy regulations, the UK Extension to the EU–US Data Privacy Framework where a provider is certified, or the UK Addendum to the EU SCCs / IDTA. The safeguard for each provider is shown in the sub-processor table.

## Infrastructure

- **Hosting location** — The application runs on Vercel and the database on MongoDB Atlas, both in Ireland (Dublin region). Cached public content is served from Vercel’s edge network.
- **Encryption in transit** — All connections use TLS. HTTP Strict Transport Security is enabled on our domains.
- **Encryption at rest** — The database and file storage encrypt data at rest using provider-managed AES-256 keys.
- **Integration credentials** — Credentials for services you connect (Search Console, WordPress, Ghost, webhooks) are encrypted at the application layer before storage and deleted when you disconnect.
- **Backups** — The database runs as a replicated cluster with automated backups.
- **Separate environments** — Development, preview and production are separate deployments with separate credentials.
- **Browser security headers** — Standard security headers, including HSTS, content-type, referrer and permissions policies, are set on responses.

## Application

- **Authentication** — Sign-in is by Google OAuth or a single-use link sent by email. No passwords are stored.
- **Role-based access** — Accounts have owner, admin, member and viewer roles. Permissions are checked on the server for every request.
- **Tenant isolation** — Every record is scoped to the account it belongs to. Content, settings, assistant memory and integration credentials are partitioned by account.
- **Content sanitisation** — Customer-authored content is sanitised before it is rendered to readers, and embeds are limited to an allow-list of hosts.
- **Rate limiting** — Rate limits are applied to authentication, public endpoints and other abuse-prone routes.
- **Outbound requests** — Server-side requests to external URLs (imports, research, link previews) are restricted to prevent server-side request forgery.
- **Payments** — Checkout, card storage and the billing portal are hosted by Stripe. We hold a customer reference and the last four digits of the card only.

## AI

- **No training on your content** — Prompts, content and outputs are used only to produce your result. Neither we nor our AI provider train models on them.
- **Model access** — Model requests are routed through the Vercel AI Gateway to Anthropic and attributed to the requesting account.
- **Untrusted content** — Web pages and search results are passed to models as untrusted data, not as instructions.
- **Confirmations** — The assistant asks before destructive actions. Confirmation is verified on the server.
- **Memory** — Preferences the assistant remembers are scoped to your account, and personal data is redacted before they are stored.
- **Billing** — The assistant cannot buy credits, change plans or access payment details. Autopilot has a monthly budget cap per blog.

## Data protection

- **UK GDPR and Data Protection Act 2018** — We are the controller for account data and a processor for customer content and reader data. The Privacy Policy and Data Processing Addendum apply to every account.
- **Cookies and analytics** — Our site analytics set no cookies. Reader counts on customer blogs use a hash that is discarded within 24 hours. We set no cookies on customer blogs.
- **Retention** — Retention periods for each category of data are set out in the Privacy Policy. Content is deleted 30 days after an account closes.
- **Export** — Published posts are available in Markdown at their own URL, and content can be exported from the app while the account is open.
- **Sub-processors** — Every third party that processes personal data for us is listed on this page. Additions are published at least 30 days before they take effect.
- **Google API Limited Use** — Search Console access is read-only, used only to show your own performance data in your account, and complies with the Google API Services User Data Policy, including the Limited Use requirements.

## Operations

- **Staff access** — Administrative access is restricted to named staff. Access to customer accounts is limited to support you request, security investigation and legal compliance.
- **Audit trail** — Credit movements are recorded in an append-only ledger, including manual adjustments by staff. Scheduled jobs and administrative actions are logged.
- **Secrets** — Secrets are held in the deployment platform’s encrypted environment configuration, not in source control.
- **Incident response** — A personal data breach affecting your data is notified to you without undue delay and within 72 hours of our becoming aware of it.

## Sub-processors

- **Vercel** (Vercel Inc.) — Application hosting and serverless compute, global edge network, file storage for uploaded media (Vercel Blob), cookieless web analytics, and the AI Gateway that routes our model requests. Location: Ireland (Dublin region); cached public content served from a global edge network. Added 2026-01-01.
- **MongoDB Atlas** (MongoDB, Inc.) — Managed primary database. Location: Ireland (Dublin region). Added 2026-01-01.
- **Anthropic** (Anthropic, PBC) — Large language model inference (Claude) for research synthesis, drafting, editing, scoring, repurposing and the Joe assistant. Accessed through the Vercel AI Gateway. Location: United States. Added 2026-01-01.
- **Tavily** (Tavily, Inc.) — Web research search API used by the research and competitor pipelines. Location: United States. Added 2026-01-01.
- **Stripe** (Stripe Payments UK Ltd and Stripe, Inc.) — Payments, subscription billing, invoicing, the customer billing portal and payment fraud prevention. Location: United Kingdom, European Union and United States. Added 2026-01-01.
- **Resend** (Resend, Inc.) — Delivery of transactional, notification and product-update email; receipt of inbound support email. Location: United States. Added 2026-01-01.
- **Google** (Google LLC) — Sign in with Google (OAuth); and, only for customers who connect it, the Google Search Console API for search performance data. Location: United States. Added 2026-01-01.
- **Unsplash** (Unsplash, Inc.) — Stock photography search and download for featured images. Location: Canada. Added 2026-01-01.

## Vulnerability disclosure

Contact: hello@support.getbloggable.com.

We ask that you:

- Give us reasonable time to fix an issue before disclosing it publicly.
- Do not access, modify or delete data that is not yours; use test accounts you own.
- Do not run denial-of-service, spam, social engineering or physical attacks.
- Stop and tell us immediately if you encounter personal data belonging to someone else.

We commit to:

- Acknowledge your report within 2 business days.
- Keep you informed of our progress and tell you when the issue is fixed.
- Not take legal action against research carried out in good faith under these terms.
- Credit you, if you wish, once the issue is resolved.

We do not currently run a paid bug-bounty programme.

## Frequently asked questions

### Where is my data stored?

The application runs on Vercel and the database on MongoDB Atlas, both in Ireland (Dublin region). Cached public content is served from Vercel’s edge network. Other providers and their locations are listed in the sub-processor table.

### Do you use my content to train AI models?

No. Your content is sent to our AI provider only to produce the result you asked for, and neither we nor the provider train models on it.

### Who can see my content?

Members of your own account, according to their role, and the public once you publish. Our staff access accounts only for support you request, security investigation or legal compliance.

### Do you have a Data Processing Addendum?

Yes. It applies automatically to every account and is published at /legal/dpa. A countersigned copy is available on request.

### Can I delete my data?

Yes. Closing your account unpublishes your blogs and starts a 30-day export window, after which content is deleted from live systems. You can also ask us to delete specific data at any time.

### Do I need a cookie banner on my blog?

Not because of us. We set no cookies on customer blogs and reader counts are cookieless. If you embed third-party content such as video, that platform may set cookies and you are responsible for any notice it requires.

### How do I report a security vulnerability?

Email hello@support.getbloggable.com with “Security” in the subject line, or use the security.txt file at /.well-known/security.txt.

### How will I know if you add a sub-processor?

The list on this page carries the date each provider was added. Additions are published at least 30 days before they take effect, and material changes are emailed to account owners. You can object under the DPA.


Source: https://getbloggable.com/trust