Troubleshooting & FAQ

← Security & API Keys · Home

Troubleshooting #

Claude says it can’t reach / connect to my site #

• Local site + claude.ai (cloud) or Claude Desktop: neither can reach a .local/localhost address — both broker connector requests through Anthropic’s servers. A trusted local HTTPS cert does not help (the issue is reachability). Use a tunnel (e.g. cloudflared), or connect with Claude Code on the same machine (it works locally; the Desktop app does not). See Connecting a local site.
• Wrong/expired key: if you regenerated the key — or deleted and reinstalled the plugin — the old MCP URL stopped working. Copy the current MCP URL from Divi Connect → Connection, then delete the connector in Claude and add it again. ⚠️ Editing the existing connector is not enough: claude.ai keeps sending the URL it already has, so a corrected key looks like it changed nothing.
• Not HTTPS: claude.ai requires a reachable https:// URL.
• Security plugin / firewall: a WAF or security plugin may block requests. Allow the /wp-json/divi-connect/v1/ routes.
• Your host’s anti-bot protection is silently blocking Claude. This one is worth its own section, because the site tests healthy from every angle while it happens — see My host is blocking Claude below.

First, work out WHICH failure you have: ask your host for the status code #

The “couldn’t register with your site’s sign-in service” error covers at least two
completely different faults, and they have opposite fixes. One question separates them.

Ask your host: “in the access log, what status code did requests to
/wp-json/divi-connect/v1/mcp/… return?” Every host can answer this in a minute.

⚠️ Before you send anyone a log file, replace your key with <key>. Your connector
key is the last part of that URL, so it appears in full in your host’s access log — and
anyone holding it can edit your site. Write the path as
/wp-json/divi-connect/v1/mcp/<key> when you describe it, and if you have already sent a
log containing it, or someone has read those logs on your behalf, regenerate the key
afterwards in Divi Connect → Connection (then delete and re-add the connector, since
the URL changes).

If your host says there are no such requests, that is not a dead end — it is the answer.
A challenge issued at a host’s edge or proxy layer is answered before the request reaches
the web server, so it never appears in the site access log. Measured on a real customer
site: across a seven-minute window containing a live connection attempt, the access log
held nothing but the WordPress admin heartbeat and wp-cron — while that same log recorded
curl and the plugin’s own self-test hitting the identical path without trouble. The
requests were genuinely arriving and genuinely being turned away, and no log the site owner
could read showed either fact.

This is why the failure is so hard to recognise, and why a host can say “we are not
blocking anything” in complete good faith. Ask them to check the bot-protection or
challenge logs upstream of the web server, not the site access log.

Two things worth knowing about the credential row, because it is the one that wastes the most
time. A 401 is the MCP specification’s signal to begin looking for a sign-in service —
so a rejected credential makes Claude go hunting for OAuth, fail, and report a sign-in
problem for what was only ever a wrong key. Divi Connect deliberately returns 403
rather than 401 for exactly this reason, with a message naming the real cause. And if the
key changed at any point — you regenerated it, or deleted and reinstalled the plugin — then
editing the connector will not help, because claude.ai keeps sending the URL it already
has.

My host is blocking Claude (anti-bot / bot-fight protection) #

This is the single hardest connector failure to recognise, because your site looks perfectly healthy the whole time. If Claude says it can’t connect — or shows a “couldn’t register with this site’s sign-in service” / OAuth-style error — and you have already checked the URL, the key, HTTPS and the plugin, this is the next thing to suspect.

Why you can’t see it:

• Our Connection self-test can’t detect it. That test runs from your server to itself, so it never carries Claude’s IP address or user agent. It can be green while every one of Claude’s requests is being turned away.
• Your security plugin’s log will be empty. The block happens at your host’s server/edge level, above WordPress — so the plugin never sees the request and has nothing to log. An empty log is not evidence that nothing is being blocked.
• Your own tests will pass. A few spaced-out checks from your browser or curl look fine. Claude fires around ten requests in a few seconds, which is what trips it.

There are two different versions of this, and they need different fixes:

It may not be policy — it may be an accumulated reputation state #

Worth trying before the harder ask. This block is not applied to every site on an affected host. Other SiteGround customers run the same kind of integration successfully — one publicly documented case had the connector complete normally, with only a separate /.well-known/ problem in the way.

Published reverse-engineering of SiteGround’s challenge shows it tracks address reputation, and that the marker in the challenge URL escalates: y=ipr: is the initial state, y=ipc: appears once that address has been challenged repeatedly. So a site showing ipc: may be in an accumulated bad state — made worse by every failed retry — rather than blocked by design.

That makes “please reset the anti-bot reputation for this site” a much smaller thing to ask than “please exempt this path from your security”, and worth asking first. A practical corollary: stop retrying a connection that keeps failing. Each attempt appears to deepen the state you are trying to get out of.

What to send your host. The details below were captured from real traffic, not taken from documentation — hosts tend to act on observed evidence and to bounce anything that sounds like a plugin problem:

⭐ On SiteGround, lead with their own allowed-crawler policy #

SiteGround publish a list of AI crawlers allowed on their servers at siteground.com/kb/allowed-ai-crawlers, and Claude-User is on it — the exact user agent Claude’s MCP requests carry. So their Anti-Bot AI is challenging traffic their own published policy permits.

That turns the request from “please weaken my security” into a defect report, which is a much easier thing for support to act on. Say explicitly that you want an exemption from the Anti-Bot AI itself, not an entry in Site Tools > Security > Blocked Traffic — that is a block list with no allowlist and does not affect what the Anti-Bot AI challenges. There is no customer-facing toggle for it, so a ticket is the only route.

Please exclude your anti-bot / CAPTCHA challenge for this site's /wp-json/ REST API
requests, at the server/edge level (not in a WordPress plugin).

On SiteGround specifically: your own KB page "AI Crawlers Allowed on SiteGround
Servers" (https://www.siteground.com/kb/allowed-ai-crawlers) lists Claude-User as an
allowed user chat session crawler. The requests being challenged carry exactly that
user agent, so this is your Anti-Bot AI not honouring your published policy. Please
exempt this traffic from the Anti-Bot AI itself - not via Blocked Traffic, which is a
block list only.

Automated requests from Anthropic's Claude service are being challenged instead of
served. Observed details:

  Source IPs   : 160.79.106.34, 160.79.106.35
                 (ASN 396982, "Anthropic, PBC")
  Allowlist    : 160.79.104.0/21   <-- the /21, please, NOT the /23 on the same page.
                 Anthropic publish this as their OUTBOUND range at
                 https://platform.claude.com/docs/en/api/ip-addresses and state it
                 will not change without notice. The /23 and IPv6 ranges on that page
                 are INBOUND; allowlisting those instead will not affect this traffic,
                 because 160.79.106.x is inside the /21 but outside the /23.
  User agents  : "Claude-User" (the MCP calls) and "python-httpx/0.28.1" (the
                 discovery requests that follow a failure). Please allow both.

Anthropic document this exact failure mode and prescribe this exact fix, at
https://claude.com/docs/connectors/building/troubleshooting :
  "If your hostname resolves correctly but a CDN, WAF, bot-management rule, or rate
   limiter in front of your server blocks the request, the connection fails before
   your application sees it. ... Allowlist Anthropic's published outbound IP range in
   your WAF or CDN configuration, or exempt your MCP and OAuth paths from the
   blocking rule."

The behaviour: the FIRST request returns HTTP 200 with correct JSON. The requests
immediately after it return HTTP 202 with an HTML challenge page instead of JSON,
which the client cannot parse. Because the first request succeeds, the site appears
healthy in every test — this is only visible in captured traffic.

Please also confirm whether this setting is per-site or account-wide.

⚠️ If you use a Cloudflare Worker to rewrite the User-Agent, keep that string CURRENT #

A hosting provider has told us directly that they block outdated Chrome versions as well as generic library user-agents, because old browser strings are what malicious bots use. So a Worker that pins, say, Chrome/125 stops helping once real Chrome has moved on, and eventually becomes a reason to be blocked.

If you use the Worker workaround, set the User-Agent to a current Chrome version and update it occasionally — or use an honest identifying string like DiviConnect/1.0, which some hosts prefer because it is attributable. Which one works depends on the host: an Anubis-style challenge specifically wants a browser, so it needs the Chrome form.

A relay cannot fix the rate-based variant. Settled by measurement, 2026-07-30. #

This was tested twice and the second test isolated the variable properly, so it is worth writing down rather than re-deriving.

Attempt 1 relayed through a Cloudflare Worker built the obvious way, copying the incoming headers through. Still challenged. The reason turned out to be a flaw in the relay, not a fact about the host: Cloudflare hands a Worker the original caller’s address in cf-connecting-ip and x-real-ip, and hosts trust those headers to identify the visitor. The relay was forwarding Anthropic’s IP on every request, so it anonymised nothing. Proof, straight out of the host’s own challenge URL: &y=ipr:160.79.106.35:...

Attempt 2 deleted cf-connecting-ip, x-real-ip, x-forwarded-for and true-client-ip before forwarding. That worked at what it was for: the challenge URL then read &y=ipc:2a06:98c0:3600::103, a Cloudflare address. The host could no longer see the original caller.

It was challenged anyway. So the host is challenging datacenter address ranges in general, not Anthropic in particular, and no relay helps — every relay you can rent is in a datacenter as well. Only the host can fix this variant.

Two things worth keeping from the exercise: a relay used for the user-agent-based variant (Anubis, LWS) should still strip those headers, and it should return a plain 404 for /.well-known/* and /register rather than relaying them, because those are questions about the relay host and forwarding them into the MCP path produces a confusing error where a 404 belongs.

⭐ If your host will not budge: connect from YOUR machine instead #

This is the one workaround that does not need the host’s cooperation, and for a host that blocks by IP reputation it is the only one that works.

Why it works. A connector added in claude.ai (or through Claude Desktop’s Connectors screen) is brokered by Anthropic’s servers — Anthropic’s own troubleshooting doc puts it plainly: “The CLI and curl connect from your machine, while claude.ai connects from Anthropic’s servers.” A locally-configured client instead makes the request from your own computer, on your own internet connection — which host bot-protection treats completely differently. We measured this on an affected site: 50 requests from an ordinary home connection, across five different user agents including Anthropic’s own, were never challenged once. The same requests from Anthropic’s range were challenged every time.

Route 1 — Claude Code (simplest). In a terminal on your own machine:

claude mcp add --transport http divi-connect "<your Divi Connect connector URL>"

Then /mcp to confirm it connected. Nothing else changes: same site, same key, same tools.

Route 2 — Claude Desktop with a local bridge. Prefer Route 1 if you possibly can. This one works, but every way of getting it wrong fails silently — Claude Desktop simply shows no server and no error — and we hit three of those in a row while testing it: the snippet below is a complete JSON document, so pasting it onto the end of a config that already has one breaks the file; there can be several copies of claude_desktop_config.json on one machine and only one is live (the folder that also contains a logs sub-folder, whose name may carry a suffix such as Claude-3p); and the app must be fully quit and reopened, which can hang without telling you. Read all three notes after the snippet before you start.

Add your connector to claude_desktop_config.json so a small local process makes the call, rather than adding it through the Connectors screen:

json
{
"mcpServers": {
"divi-connect": {
"command": "npx",
"args": ["-y", "mcp-remote", "<your Divi Connect connector URL>"]
}
}
}

Restart Claude Desktop afterwards. (npx comes with Node.js.) Users of other WordPress MCP plugins on blocked hosts report this route working where the Connectors screen does not — same mechanism.

⚠️ Which clients this actually covers. This is the part to get straight before spending time on it:

How you connect	The request comes from	Works on a blocked host?
claude.ai in a browser	Anthropic’s servers	No
Claude Desktop → Connectors screen	Anthropic’s servers	No
Claude Desktop → claude_desktop_config.json	your own machine	Yes
Claude Code	your own machine	Yes

Note the second row: adding a connector inside Claude Desktop does not help, because that screen is still brokered by Anthropic. Only the manual config route is local.

So if you need to use Claude in a browser, this workaround is not available to you and your host has to make the change. There is no way around it from the WordPress side: any relay, proxy or hosted middleman still arrives from a data-centre address, which is the thing being judged. Only a request genuinely originating on your own computer passes.

What you give up. A cloud connector works from anywhere, including your phone. A local one only works on the machine you set it up on, while that client is running. That is the whole trade: you swap “works everywhere” for “works at all”.

⚠️ This removes the datacenter signature, not the not-a-browser signature. It is directly measured to work against SiteGround’s Anti-Bot AI; a host that challenges every non-browser client regardless of address could in principle still refuse. If yours does, say so and we will document it.

After the host changes anything: delete the connector in Claude and add it again (see the warning under I updated Divi Connect but Claude can’t see the new tools/features) — editing or retrying it will keep failing even once the block is gone.

If you use Cloudflare yourself, check these three things #

Separate from your host: if your domain is proxied through Cloudflare (orange cloud, not
DNS-only), Cloudflare has its own bot protection that can block Claude before your host ever
sees the request. All three fixes below work on the free plan, and all three need the
domain proxied.

1. An Allow rule does NOT override Cloudflare’s AI bot blocking. This is the trap worth
knowing first, because it makes people think they have already fixed it. If Manage AI Bots
or Bot Fight Mode is on, it evaluates at a higher priority and silently overrides any
custom Allow rule — so allowlisting Anthropic’s IP range or your MCP path is not enough on its
own. Either scope the AI-bots rule off this hostname, or add a WAF rule that explicitly
Skips the managed rules for your MCP path:

If  URI Path contains  /wp-json/divi-connect/v1/mcp/
Then  Skip → All managed rules

Turn Bot Fight Mode off briefly to test. If that fixes it, you know this is your problem.

2. Rewrite the user agent, if your host blocks on it. For hosts that filter on the agent
string rather than the address — WP Engine and Bluehost both block user agents containing
python, which is what Claude’s connector sends on some requests — a Transform Rule fixes it
at the edge, with nothing to install:

Rules → Transform Rules → Modify Request Header, set static header User-Agent to
AnthropicMCP/1.0, matching:

starts_with(http.request.uri.path, "/wp-json/divi-connect/v1/mcp/") and lower(http.user_agent) contains "python"

⚠️ This does not help on hosts that judge the source address instead, SiteGround among
them — we have measured that directly. Use it for a user-agent block, not for an address block.

3. Stop the endpoint being cached. A cache in front of the REST API can serve a stale
response to a live connection. Add /wp-json/divi-connect/v1/mcp/* to whatever caching you
run — Cloudflare Cache Rules → Bypass cache; on SiteGround, SG Optimizer → Caching →
dynamic-cache URL exclusions; in LiteSpeed / W3TC / WP Fastest, “Do Not Cache URIs”. This is
free, takes a minute, and removes a variable — worth doing before you spend time on anything
harder. (SiteGround’s dynamic cache does sit in front of /wp-json/: an affected site returned
X-Proxy-Cache: HIT there.)

Credit: these are adapted from Meow Apps’ write-up, which documents the same fixes for another WordPress MCP plugin.

The connector was added but Claude has no tools #

• Start a new chat after adding the connector.
• Make sure the connector is enabled in Claude’s connector settings.
• In Claude Code, run /mcp to confirm divi-connect is listed and connected.

Claude Code asks permission for the wrong site’s connector #

If you have several sites, each with its own Divi Connect connector, Claude Code
can occasionally ask permission for a different connector than the one you meant.
This is Claude Code’s connector picker (client-side), not the plugin. Two things help:

• Each Divi Connect connector names itself by site — the permission prompt shows
  Divi Connect - <Your Site Name> (yourdomain.com), so you can tell them apart and
  approve the one matching the site you’re working on.
• If Claude Code still reaches for the wrong one, deny it and send your request
  again — it then asks for the correct connector.

A design-system push fails with “No Divi theme is active” / “needs Divi 5” #

Divi Connect checks for an active Divi 5 theme before writing colors, variables or
presets. If you see this, the site either has no Divi theme active (install &
activate Divi) or is on Divi 4 (update to Divi 5.0+). The plugin also shows a
warning banner on the Divi Connect and Plugins screens until Divi 5 is active.

I updated Divi Connect but Claude can’t see the new features #

Claude caches the connector’s tool list from when you added it, so after an update it keeps using the old one — which makes new features look “missing,” or Claude will say it can’t do something it now can.

Fix: delete the connector and add it again (claude.ai / Desktop → Settings → Connectors → remove, then add; Claude Code → claude mcp remove divi-connect, then add), then start a new chat. After re-adding you should see exactly three tools — divi_discover, divi_describe and divi_execute. A long list means the old one is still cached.

You only have to do this once. From 2.3.0 the tool list no longer changes when features are added, so after this reconnect later updates need none. A connector still holding the old list keeps working in the meantime.

⚠️ Delete and re-add — do not just edit it, refresh it, or toggle it off and on. Those do not reliably replace what Claude has cached, and they do not replace the connector’s URL: if you change the URL of a connector that already exists, claude.ai keeps sending the old one no matter what you paste in. See Connecting Claude → After updating.

Claude says it will not build part of the page as raw HTML #

This is deliberate, and the message names the way round it. A block of hand-written HTML cannot be edited in the Visual Builder and ignores your design system, so a page containing one is a locked box in your layout — which is the most common way an AI-built page ends up unmaintainable. From 2.3.0 Divi Connect declines to write raw-HTML blocks or hand-written inline styling unless you have actually asked for them, and tells Claude what to use instead: real modules, your presets and your own colours.

If you genuinely want a raw block — a third-party widget, a booking script, an SVG you supplied — say so and it will be written. Pages that already contain one keep working and stay editable exactly as before; nothing was changed on your existing site.

“Install ready-made styles” stops and says they have nothing to bind to #

A preset holds no values of its own: every size and colour in it points at one of your site’s, by name. On a site that has no colours or sizes yet, the styles would install, appear in the picker, and change almost nothing when applied — so from 2.3.0 Divi Connect checks first and stops instead of writing them.

It offers two ways forward:

• Install the colours, fonts and sizes too. Everything resolves and the styles work fully.
• Sizes only. Everything still installs and the sizing works; the message tells you how many colours the styles use that your site does not have, and anything painted with those falls back to Divi’s own default until you add them. You can install the colours later and nothing needs re-applying.

If your site already has its own colours and sizes, you will not see this at all — the check only stops an install that would achieve nothing.

Tools intermittently hang / time out (then a retry works) #

Fixed in 1.7.5 for the most common trigger. The biggest single cause was divi_get_rendered_page: to show you a page it used to make the site fetch its own URL (a loopback), which needs a second PHP process at the same time — enough to exhaust a small hosting plan and produce hangs or 503 errors. As of 1.7.5 that tool renders the page in-process with no loopback, which removes the connector’s own contribution to the stall (reproduced on a real shared host: 503s eliminated, ~3.5× faster under load). Update to 1.7.5 and reconnect if you’re hitting this.

Any remaining intermittent hangs — calls that stall then succeed on retry, not tied to page size or one tool — are on the hosting side, below the connector. Common causes: too few PHP‑FPM workers (one slow request starves the rest), WordPress running its cron on page loads (WP‑Cron), or a slow ping from another plugin. Checks, quickest first:

• Run real cron instead of on-request cron. In wp-config.php add define('DISABLE_WP_CRON', true); and add a real server cron hitting wp-cron.php every few minutes. This stops random visitor/tool requests from blocking while WP runs scheduled jobs.
• Give PHP more workers. On managed/cheap hosts the PHP‑FPM pool can be very small (2–4). Raising pm.max_children (or moving off a starved plan) removes the “one slow request blocks everything” pattern.
• Add persistent object caching (Redis/Memcached) if the host offers it — cuts repeated option/query cost.
• Retry is usually safe for reads and edits; see the retry‑safety note below before re‑running a create/delete.

Is a timed‑out call safe to retry? A timeout means the client gave up waiting — the server may still have finished. So it’s per‑tool:

Deeper host‑side diagnosis (for site admins) is in docs/TIMEOUTS-DIAGNOSIS.md.

“Invalid Divi Connect key in connector URL” #

The key in your MCP URL doesn’t match the site. Recopy the MCP URL from the settings page (it may have been regenerated or copied incompletely).

Claude built a page but it looks blank or broken #

The plugin validates markup and rejects malformed pages, so a published page should render. If something looks off, ask Claude to rebuild it as a draft and review it in the Divi builder, or tell Claude exactly what’s wrong (“the hero section is empty”) so it can fix the markup.

Saving a global preset fails in the Divi builder (site-wide) #

If the Divi builder suddenly refuses to save any global preset, one malformed preset in your store is likely blocking them all. Just tell Claude “repair my presets” — it normalises every preset back to the current format without changing your styling, which unblocks saving. (Newer builds also clean presets as they’re saved, so this shouldn’t recur.)

A Pro feature returns an error / “402” #

That feature (editing colors/variables/presets, Theme Builder, global layouts, WooCommerce pages, or linked size variables) requires Divi Connect Professional. See Free vs Pro.

I changed a size token but my Free-plan page didn’t update #

On Free, size variables are baked into the page at build time. Upgrade to Professional to keep them linked, or ask Claude to rebuild the page. See the explanation here.

I deleted a page by mistake #

Pages are moved to Trash by default (not permanently deleted). Recover it from WordPress → Pages → Trash. Only a page deleted with explicit “permanent” confirmation is unrecoverable.

Things that look broken and are not #

Everything in this section has been reported at least once and is working as intended.
Worth a read before you write in — it is faster than waiting for a reply, and these are the
ones that come up most.

Over a hundred presets are all called “DL Base” #

Exactly 105 of them, and it is neither duplication nor a naming bug. Divi keeps presets in
separate buckets — one for text, one for buttons, one for spacing, one per module kind —
and each bucket needs its own neutral starting point. They share a name because they do the
same job in different places, and Divi only ever shows you the ones for the thing you have
selected. The same goes for “DL Card”, “DL Bordered”, “DL Flat” and “DL Elevated” appearing
several times over.

Some presets look wrong until you put them on a dark background #

Around forty presets are painted in light ink on purpose. Anything named On Inverse,
Dark, or Badge On Success / Warning / Danger is meant for a dark or coloured band. Apply
one to an ordinary white section and the text will seem to vanish — that is the preset
working correctly in the wrong place. Put it on a dark section and it reads fine.

The preset numbers in different places don’t match #

They are counting different things, and all of them are right:

• Installed counts every preset in your Divi store — which includes ones you or your
  theme made, so it can legitimately be higher than the number we shipped.
• Shipped counts what is in the design pack this version carries.
• The catalog groups them by family, so the number of rows is smaller than the number of
  presets.

Divi Connect → Troubleshoot → Reporting a problem prints the installed and shipped
figures side by side, so you can see the two numbers rather than guess which one is wrong.

A border-radius is set but nothing looks rounded #

A rounded corner is only visible on an element that actually paints something — a
background, a border, or a shadow. Set a radius on a transparent element and there is no
edge to round, so nothing changes. Padding does not count. Give the element a background or
a border and the radius appears.

Home still shows the setup checklist after everything is installed #

By design. Home stays on the first-run checklist until Claude has actually reached your
site — not until the plugin is configured, and not until the self-test passes. A site can
be perfectly set up and still never have been contacted, which is the single most common
real fault, so the checklist is deliberately the last thing to go. Once a request from
Claude arrives, Home switches to the normal dashboard on its own.

Absolute positioning and mobile/tablet variants “aren’t applied” #

They are. Both were reported as broken and both were measured working end to end: absolute
and relative positioning render, and per-breakpoint values apply on phone and tablet. If a
layer looks like it is in the wrong place, check the origin — a centred origin relies on
a translate(-50%) that is doing real work, and overriding it by hand is usually what moved
the element.

⚠️ One genuine exception: position: sticky currently faults inside Divi itself. That one is
a real bug and it is Divi’s, not ours — use absolute or relative until it is fixed upstream.

Text went invisible after I deleted a colour in Divi #

This is a Divi behaviour worth knowing about: deleting a colour in Divi’s Variables panel
archives it rather than removing it. Anything pointing at that colour is left with
nothing to resolve, so the text falls back to your site’s global ink — which on a pale
background often means it disappears.

You do not have to rebuild anything. Divi Connect → Design System shows a “Restore
colours that were deleted” card whenever it finds this, naming each missing colour, and
Apply puts them back at the exact values they had. The card only appears when something is
actually missing, so if you cannot see it, this is not your problem.

The diagnostics block says my install “may have been updated in pieces or edited by hand” #

That line reports, it does not accuse. It compares when your plugin files were written:
a normal install writes them all within a second or two of each other, so a scattered spread
usually means a partial update. But it reads exactly the same way if you deliberately edited
a file, or if your host deploys in stages. If you have not touched anything and you see it,
re-installing the plugin fresh is a reasonable thing to try; nothing is wrong on its own.

admin-ajax.php returns 0 #

If you have been looking in the browser’s network tab: a bare 0 from admin-ajax.php means
you are not logged in for that request — it is WordPress’s “no such action for a logged
out user” reply, not an error from us. (-1 is the authenticated-but-refused reply.) This
almost always means a session expired in another tab. Log in again and retry.

FAQ #

Does it work with a free Claude account?
Yes. Free claude.ai accounts can add the custom connector and build pages.

Does my site need to be publicly reachable?
For claude.ai (cloud) and the Claude Desktop app, yes — both broker requests through Anthropic’s servers, so the connector URL must be publicly reachable over HTTPS (use a tunnel for a local site). Only Claude Code running on your own machine can use a local site directly.

Does it require Divi 5?
Yes. Divi Connect targets the Divi 5 builder (5.7+). It does not work with the Divi 4 / legacy builder.

Is it secure?
Each site has its own secret connector key, shown in Divi Connect → Connection, and you can regenerate it at any time to instantly invalidate the old one. See Security & API Keys.

Will it change or delete my existing design system?
No. Reading the design system never changes it. Editing it (a Pro feature) only happens when you explicitly ask Claude to. Uninstalling the plugin removes only the plugin’s own settings, never your Divi data.

Can I use it on multiple sites?
Yes — install it on each site. Each gets its own connector. The Pro 1 / 5 / Unlimited plans (and Lifetime, which is unlimited) cover how many sites can use the Pro features at once.

Can Claude edit a page it already built?
Yes — ask it to make changes and it will update the page. You can also keep editing in the Divi builder as normal.

What happens to my pages if I deactivate the plugin?
Your pages are normal Divi pages — they stay exactly as they are. The plugin only provides the connection; it isn’t required to display pages it built.

Still stuck? #

• Check Things that look broken and are not above — the most-reported issues are on that list, and none of them needs a reply from us.
• Re-check Divi Connect → Connection and recopy the current MCP URL.
• Try the Quick test curl command on the settings page to confirm the API responds.
• Still stuck? Email [email protected] — the one address for problems. Open Divi Connect → Troubleshoot → Reporting a problem, press Copy diagnostics, and paste that block into your message along with what you asked for and what happened instead. It describes your installation, so you get an answer rather than three more questions. We reply within one working day.
• ⚠️ Never include your full connector URL or API key in a public message — regenerate it first if you think it leaked. (The diagnostics block deliberately contains neither.)

← Security & API Keys · Home