01 Overview
Three writers, one website, and every page they wrote copied into it by hand.
The documentation team wrote in Google Docs and sent each finished document to our team, who rebuilt it in WordPress and sent it back for review. The client asked for a new project, and for us because we knew the system by the back of our hand: we had designed its UI.
01.1 The problem
Every page copied whole, reviewed, and copied again until it was right.
One row, because the work had one layer: what went wrong, what it cost, and what we did about it.
| What was going wrong | What we did about it | |
|---|---|---|
| Automation problem Each document was copied into WordPress by hand: one to two days, up to three for long ones. Nobody could pin what had changed, so the whole page was copied every time, then reviewed, and every fix went round again. Almost a week from finished document to live page, with two a week at most. | A pipeline from the writer's folder to WordPress: n8n converts each document, emails the writer a preview, and publishes it when they accept. | See the work |
01.2 The timeline
Hired in April 2026, live in the first week of May, and still running.
A new contract, separate from the site work, built by one person in about a month.
- 2026April
A new contract to automate how documentation gets published.
- May
The writers start publishing through it in the first week, and our part ends that month.
- November
Still running.
01.3 Context
A security company with no infrastructure for automation, and writers who had never needed formatting rules.
What the work started from, before any of it was ours to change.
Late to automation
The client was "very late in terms of adapting to technologies like that", with no infrastructure in place for automations.
Locked down
As a security company, it had API access to WordPress disabled. The pipeline's one blocker was opening it for the user n8n publishes as.
Why us
The client knew Chris was moving into automation, and had heard about him tinkering with it. Designing systems has been his strong point "ever since. That's why I am a web developer."
The writers
A documentation team of three, unnamed here, writing in Google Docs.
02 Automation solution
Write it, save it, approve the preview, and the page is live.
Nothing about how the writers work changed except where they save the file. Everything between their document and the live page, the copying, the rebuilding and our side of the review, is now n8n's, and the only person who checks the page is the one who wrote it.
02.1 The pipeline
The whole pipeline, from a writer's folder to a live page.
The workflow from above: where a document goes, what n8n does with it, and the one place a person steps in. The sections after it are the parts, what they replaced, and the calls behind them.
- Stage and preview
- The folderGoogle Drive, every 30 min
- ConvertDoc to HTMLWon't convertError logTo senior doc staff
- PreviewOutside the site
- EmailTo the writer
- The writerAccepts or declines
- Accept
- Publish
- BlocksHTML to WordPress blocks
- PublishWordPress REST API
02.2 How it fits together
A folder in, a preview in the middle, and WordPress at the end.
Writers save to a Google Drive folder n8n checks every 30 minutes. Each document becomes HTML, then a preview that is a 99% perfect copy of the live page but not part of the site, emailed to whoever edited it. When they accept, n8n turns the HTML into WordPress blocks and publishes it through the WordPress REST API.
02.3 The parts
Seven parts, one of them a person.
What went in, named as the writers meet it, and where each one runs.
| The part | What it does | Where it runs |
|---|---|---|
| The folder | Where a finished document is saved, the writers' only new habit. | Google Drive, checked every 30 minutes. |
| The conversion | Turns each document into HTML, under formatting rules the writers follow. | n8n, on our own server. |
| The preview | A 99% perfect copy of the live page: the content exactly as it will read, without the site's navigation and sidebars. | Outside the site, so nothing is live yet. |
| The email | Sends the preview's link to whoever edited the document. | n8n, to the writer's inbox. |
| The writer's approval | Accept or decline: the one human step, by the person who knows the page best. | The writer, from the email. |
| The publish | Turns the accepted HTML into WordPress blocks and puts the page live. | WordPress, through its REST API. |
| The error log | Reports a document that won't convert. | To the senior documentation personnel. |
02.4 The workflow shift
Every step between the writer and the live page, and who does it now.
Each row is a step a document passed through, how it used to run, and how it runs now. The writing didn't change; everything after it did.
| Before | After | What it saved | |
|---|---|---|---|
| Handover | Sending each finished document to our team to be built. | Saving it to one Google Drive folder. | No ticket, no waiting on a developer. |
| Copy | Copying the whole page into WordPress by hand, one to three days, because nobody could pin what had changed. | n8n converts the document and builds the page from it. | No page copied by hand. |
| Review | The client reviewing our copy for about a day, and every fix going round again. | The writer reviews their own preview and accepts or declines it. | The writers became the QA, checking only their own changes. |
| Publish | Publishing once the loop was approved. | The page goes live on accept. | Live the moment it's approved. |
02.5 The automation process
One rule set for writing, settled in testing, so a document converts the way it reads.
Google Docs don't translate into HTML perfectly. Testing went back and forth until the writers' habits and the conversion met in one set of formatting rules everyone could follow.
- Write in Google Docs
- Save to the folder
- Convert, every 30 minutes
- The writer's preview
- Live on WordPress
Caught at 04 The writer's preview
Formatting rules for spacing and structure, which every writer follows.
Writers spaced pages with extra line breaks, which barely show in a document but show on an HTML page.
- The result
- One cohesive rule set, followed by everyone.
- Who, and where
- The writers and us, in testing.
02.6 Automation decision
The easy builds were a button, a straight publish, or the client's own servers. It got a folder, a preview, and ours.
Three calls the pipeline turned on: where it runs, when it runs, and who checks the page before it's live.
| The call | The easy answer | What we chose | What it cost, and what it bought |
|---|---|---|---|
| Where it runs | On the client's own infrastructure. | n8n on our own server, as a service. | A security company had to open WordPress to API requests for it. An automation the client had no infrastructure to run, running from the first week of May. |
| When it runs | A publish button, or a trigger on every save. | The folder, checked every 30 minutes. | A document can wait up to 30 minutes for its preview. Nothing to click and no load on the servers, at a pace that suits documents written over one to two hours. |
| Who checks the page | Publishing straight away, or a QA for documentation pages. | A preview and an email to the writer, who accepts or declines. | Every page waits on its writer's approval. The people who know the work best check that their changes, and only theirs, went in. |
03 Field notes
What the writers said, and what the work comes down to.
What came of it: the team's own words, how it was built, and what we took away.
The documentation team
"Everything is so fast now. We've been waiting for a process like this."
Since May
An estimate, not a count: at the rate in testing, 500+ pages published without a dev ticket.
A service
The client had no infrastructure for automation, so we run it for them, and took the chance to offer it to other brands.
How it was built
With n8n and n8n's MCP: "N8N's MCP is very helpful."
Know the system
"Setting automations is magical." To automate WordPress you need to know how WordPress works; to automate HTML pages, HTML. Chris calls it the biggest takeaway of the project.
Should have been sooner
"Publishing through automation pipeline should be the standard, especially if you want speed." Anyone weighing it should think they'd have done it sooner: it belongs at the start.
04 Team and stack
One person across automation.
Built on n8n, Google Docs, Google Drive, WordPress, WordPress REST API, and HTML. Made with n8n MCP.
- Built on
- n8n · Google Docs · Google Drive · WordPress · WordPress REST API · HTML
- Made with
- n8n MCP
Chris Javier Oliveros
Automation Engineer
Set up n8n end to end, from the Google authentication and the Google Drive access it reads from to the preview pages its links send, and wrote the formatting rules the writers follow so a document converts cleanly.
- In testing, the three writers published 12 pages a day; before, a page took almost a week from document to live.
05 Impact
Up to two pages a week, by hand. In testing, 12 a day, with no page copied.
Each row is how the work ran before and after. Nothing was measured with a tool: the befores are how it ran, and the after is the rate in testing, three writers in a day.
Pages published
three writers; the after in testing12 a day
Before
Up to 2 a weekCopying into WordPress
per pageNone
Before
1–3 days, by hand