HOW IT WORKS
Just say it. Webgentic does the work.
This page is the public walkthrough: the workflow every change goes through, what you need in place before you start, and what we set up for you. Nothing here sits behind a login.
Animation: four examples of a change being asked for in plain words, and Webgentic making it. Run a sale: a new headline goes up and every price is cut by 20%. Build a landing page: a page for Saturday pottery classes is written, published and linked from the menu. Optimise for search: the terms people already search for are read from Search Console and the page is rewritten around them. Add a form: an enquiry form is built into the page and the replies are sent to the owner’s inbox. Each one ends with a note confirming what changed, and every change can be rolled back.
THE WORKFLOW
Five stages, with an approval gate before anything goes live
You describe the change in plain language. Webgentic works out what needs editing, shows you the exact difference, and waits. Nothing reaches your live site until a person approves it.
Observe
Your request, plus the site itself and any analytics you have connected
Plan
A concrete plan naming the files and content it will touch
Review
Two-stage approval with the full diff in front of you
Deploy
Git-backed commit, so every change has an author and a date
Roll back
One click returns the site to the previous version
The same five stages apply whether the request came from you or from the optimisation layer spotting a problem. An unattended change still stops at Review.
BEFORE YOU START
What you need in place
Most teams already have all of this. Anything marked optional can be added later, and the last column is work we do rather than work you do.
You need
Five things, all of them things you already control.
- A live site on a supported platform WordPress, Drupal, Magento or Shopify. Custom and bespoke sites are reviewed case by case before we quote.
- Somewhere for it to run Either our managed cloud, or your own hosting if you would rather keep everything in house.
- A Git repository for the site If the site is not in version control yet, we set that up as part of onboarding.
- A scoped admin account for Webgentic Issued by you, limited to your website directory, and revocable at any time.
- One named approver A person who signs off changes. You can add more approvers and roles later.
Useful, not required
These unlock more, but you can start without them.
- Read-only analytics access Google Analytics and Search Console. Needed before Webgentic can suggest changes off the back of real performance data.
- A staging environment Lets you approve and watch changes land somewhere safe first.
- Your identity provider For single sign-on and role-based access for your team.
- Brand and content guidelines Tone of voice, type, colour. Anything written down keeps generated work closer to your house style.
We set up
So you know what is not on your list.
- The environment Isolated, and confined to your website directory with path validation on every file operation.
- Approval workflow and roles Who can request, who can approve, who can only read.
- Platform Pathways The routing that makes output native to your CMS and page builder.
- Audit log and rollback points Every action logged, every change reversible.
Server versions, access method and connection details depend on your host, so we confirm those on the setup call rather than guessing here. If you want the specifics for your setup before committing, ask us and we will check your site first.
Send us the site and the host. We will tell you what is missing before you commit to anything.
GETTING STARTED
What onboarding looks like
Four stages, and you hold a decision point at each one.
Scoping call
We look at your site, your platform and your hosting, and tell you plainly whether it is a fit and what it would cost.
You do: show us the site
Connect
We build the environment, put the site in version control if it is not already, and connect analytics if you have chosen to.
You do: issue scoped access
First changes, supervised
You make real requests while we watch. Every change goes through the approval gate so you see the diffs and the rollback working.
You do: approve or reject
Day to day
Your team requests changes in plain language. Approvers get a diff to sign off. The audit log builds up as you go.
You do: keep asking for changes
YOUR PLATFORM
What it can touch on your CMS
Output is native to the platform, not pasted into a generic block. Each page below lists what is covered.
WordPress
Gutenberg, Elementor, Divi, Beaver, ACF, theme files, custom plugins, WooCommerce
Drupal
Layout Builder, DXPR, Paragraphs, Views, blocks, theme files, custom modules
Magento
Page Builder, Hyvä themes, CMS pages and blocks, products, categories, extensions
Shopify
Liquid themes, pages, products, collections, metafields, custom apps
Running something else, or a custom build? Tell us what it is and we will say honestly whether it fits.
DOCUMENTATION
Where the rest of the detail lives
The full documentation portal covers API references, integration guides and deployment detail. It is open to active clients, licensed partners and authorised team members, because a lot of it describes live client environments.
This page is the public version and it stays public. If you need more before you commit, the architecture page goes deeper on the system itself, and we will answer specifics about your own site on a call.
COMMON QUESTIONS
The four we get asked most
No. Requests are written in plain language, and approving a change means reading a summary and a diff rather than reading code. You do need someone with the authority to say yes, and someone who can issue access to the site during setup.
No. Every file change requires explicit approval before it is published, including changes the optimisation layer proposes on its own. What it can do unprompted is watch for problems and put a fix in front of you.
Every deployment is a Git commit, so there is a previous version to return to. Rolling back is one click and takes seconds, and the audit log shows what changed, when, and who approved it.
Webgentic runs in an isolated managed cloud environment, or on your own hosting if you prefer. Operations are confined to your website directory, analytics access is read-only, write access covers approved Git operations only, and you can revoke it at any time. The security page sets out the detail.
Anything not covered here, we will answer about your own site rather than in general terms.
Want this checked against your own site?
Tell us the platform and the host and we will confirm what is needed, what it would cost, and what the first fortnight would look like.
Book a walkthrough