Skip to main content
The copilot is a Pro feature and needs a connected provider.
Generatify > Chatbot is an assistant that knows your site. It is not a general chatbot that happens to live in WordPress: it can query your content, and it can make changes, with your approval, through a defined set of abilities.

​
The prompt box

​
control
Attach images, PDFs, or CSVs for the assistant to work from.
​
control
Reference a specific post, page, or other content so the assistant works on exactly what you mean rather than searching for it.
​
control
Choose which connected provider answers. Auto picks for you. If this reads No AI Model Available, no connector is set up.
Conversations are kept in your browser’s local storage, not in your database. They stay on the machine you used, and New Chat discards the current one.

​
What it can read

These run without asking, because they change nothing. This is what makes questions about your own site work: “which posts mention returns”, “what did I publish in March”, “who wrote the most posts last year”.

​
What it can change

Every one of these stops and asks first.

​
How approval works

Nothing is written when the assistant decides to write it. Instead:
1

It builds a preview

The change is prepared and held, not applied.
2

It describes the change to you

In plain language, in the conversation.
3

You confirm or you do not

Only on your confirmation does the change actually happen.
This is enforced in the plugin, not in the prompt. The write path returns a preview and a token instead of performing the action, and the action only runs when the pending change is applied. An assistant that decides to skip asking still cannot write anything.
Ask to see what is waiting at any point, and pending changes are listed back to you.

​
Developer abilities

The copilot can also work on the site itself: reading and writing files under wp-content, activating and deactivating plugins, and reading and setting options. This is the difference between an assistant that hands you a snippet and one that creates the child theme and fixes the broken function it just found.

​
The limits on those

Requires manage_options at minimum, plus WordPress’s own file-editing capabilities. Checked against the logged-in user both when the preview is built and again when it is applied.
Every path is resolved and must land inside wp-content. Symlinks cannot escape it and neither can ...
An allowlist of source and text extensions: php, js, mjs, jsx, ts, tsx, css, scss, json, txt, md, html, svg, xml, po, pot, yml, yaml. Anything else is refused rather than guessed at. .htaccess is deliberately excluded, because one bad directive there takes down the admin you would need to undo it.
DISALLOW_FILE_MODS and DISALLOW_FILE_EDIT are honored. A site that has locked file editing stays locked.
Every write and delete copies the previous file into uploads/generatify-backups first and returns the backup path. Nothing is removed outright.
A fixed list stays out of reach: siteurl, home, active_plugins, template, stylesheet, admin_email, new_admin_email, users_can_register, default_role, cron, db_version, initial_db_version, and recently_activated.
These protections are real, and they are not a substitute for backups. An approved change to a theme file is still a change to a theme file. Work on staging when asking the assistant to modify code, and confirm you have a working backup before approving anything structural.

​
Getting better results

Use the mention control to point at the exact post. Searching for “that post about shipping” wastes a round trip and sometimes finds the wrong one.
A request bundling five edits produces one confirmation you have to accept or reject as a whole. Separate requests are easier to review and easier to undo.
The description is generated. The preview is what will actually be written. When they disagree, the preview is right.
Long conversations carry everything forward, which costs more per request and gives the assistant more chances to conflate two tasks.