Here’s what actually happens when you hit Create.
Five things you can click “Create” on inside Blog Monkee: a Blog Post, a Campaign, a Backlink, a Mention, and a Cloud Link. What follows is the real machine that runs behind each one. No marketing gloss: this is traced directly from the running code, real function names and real external calls included, and every place the interface promises more than the code actually does is called out on purpose.
6 live hosting platforms
2 fallback AI models
100% traced to source
Everything traces back to the same publish pipeline.
A Blog Post, a Campaign, a Backlink, a Mention, and a Cloud Link all run through the same client brand profile, the same writing engine, and the same WordPress publish gate, just pointed at a different job.
PIPELINE 02CampaignOne pillar idea becomes a content calendar, chained across two job queues so it outlives the browser tab.Jump to pipeline →
PIPELINE 03BacklinkHow a “backlink site” comes into being, gets picked, and ends up actually pointing at a client.Jump to pipeline →
PIPELINE 04MentionA brand-new article that says a client’s name on purpose, with no hyperlink attached at all.Jump to pipeline →
PIPELINE 05Cloud LinkOne keyword and one URL become a live page, copied onto six different hosts at once.Jump to pipeline →
Turning one topic into a published, scored article.
Two entirely different systems can write a Blog Monkee post: a durable background pipeline and a live browser-only editor, both built to end up sounding like the same writer.
TWO FRONT DOORS
Submit a topic for a scheduled or campaign post, and it hands off to a durable background job queue. Use the live-preview editor instead, and the whole pipeline runs straight from the browser tab, calling the AI directly, with no queue and no safety net if the tab closes.
POST /api/jobs/content/generate → BullMQ content-generation queue · or contentGenerationService.ts → geminiService.ts direct
GROUNDED IN WHAT’S ALREADY RANKING
Before a word is written, the topic is checked against live Google results: competitor pages, “people also ask” questions, related keywords. That way the outline isn’t working from imagination alone.
EVERY PROMPT REBUILT AROUND ONE CLIENT
The client’s business name, industry, audience, and value proposition go straight into the prompt. If a full brand profile exists, the writer also inherits a required tone of voice, key terminology, a list of forbidden phrases, and real writing samples to imitate. The instructions are explicit that this is a dedicated writer for one business, not a generic assistant giving generic advice.
A QUIET FALLBACK WHEN THE AI STUMBLES
If the primary model gets overloaded or throttled mid-generation, the exact same prompt, client profile included, retries automatically on a second model, and the reverse holds true if that second model is the default. The reader never sees the hiccup.
Gemini ⇄ GPT-4o-mini, 120-second timeout race
SOURCING THE LINKS AND THE PHOTOS
Real cited sources and top competitor pages become the outbound links; if fewer than two survive, the client’s own RSS feeds get searched for something close enough. Photos come from the client’s own image library first, each one checked so a broken or private link can’t slip through, with stock photography filling whatever’s left.
A PUBLISH GATE THAT CAN SAY NO
Right before a post goes live on WordPress, the system scans the finished page for any image still pointing at a private storage link or a raw embedded file. It refuses to publish outright rather than ship a page with broken pictures.
assertNoBrokenImageHosts() inside publishToWordPress()
BEHIND THE CURTAIN
Two genuinely separate systems write blog content: a durable backend pipeline and a live browser-only one. A prompt fix made in one doesn’t automatically reach the other.
Search-engine indexing pings aren’t fired automatically after every publish. That’s a separate, batched action a person triggers afterward for everything at once.
One pillar idea becomes a content calendar.
A single flagship topic gets handed off across two chained job queues, so the whole run keeps executing long after the tab that started it is closed.
PLAN THE PILLAR
Pick the money-site client, write one flagship topic, choose whether this run is meant to build backlinks or plant mentions. The AI then turns that single idea into a list of supporting-post topics.
WHO DECIDES WHERE EVERYTHING LIVES
A separate execution step sets the start date, the days between each post, and a placement mode; everything stays on the main site, everything spreads across a set of backlink sites, or a mix of both. The assignment itself is plain arithmetic: post one to site one, post two to site two, wrapping back around once the list runs out.
backlinkClientIds[i % backlinkClientIds.length]
WHOSE VOICE ACTUALLY WRITES IT
The pillar post is written in the main client’s own voice, exactly like a standalone Blog Post. Every supporting post is written in whichever client it actually lands on: the main client’s voice if it stayed home, but the destination site’s own tone, audience, and forbidden phrases the moment it rotates out to a backlink site.
SURVIVES CLOSING THE LAPTOP
The flagship post runs synchronously in the tab that started it, then publishes immediately. Once it’s live, its web address is handed to a background queue that fans every supporting post out to the real content-generation queue, durable and completely independent of the browser that started it.
A REPORT LANDS IN THE INBOX
Once every post in the run has finished or failed, a full report (per-post SEO score, word count, status) is sent to the campaign’s owner.
Sent via the GoHighLevel messaging API
BEHIND THE CURTAIN
There’s an elaborate “Campaign Link Strategy” data model in the database: domain-diversity rules, anchor-text rotation, authority thresholds. None of it is actually called anywhere in the live pipeline. The real backlink mechanic is a one-line URL added to the list of links a supporting post’s writer is given.
What counts as “a backlink” is purely whether the post landed on a different domain than the pillar’s home site, regardless of whether the campaign was labeled “backlink” or “mention” going in. And if a campaign has cloud-linking turned on, finishing the queue also fires off the Cloud Link pipeline automatically, at the same money URL.
How a “backlink site” comes into being.
How it gets picked, and how it actually ends up pointing at a client.
TWO WAYS IN
Add one site by hand, filling out the same client form with a toggle flipped from “Client” to “PBN,” or import an entire network of existing sites at once from Easy Blog Networks, a marketplace of ready-made link sites.
BULK IMPORT DOES THE WORK OF SCALE
Paging through the network’s catalog, every site is labeled a backlink site and stamped with whatever that network already knows about it: its domain authority score, whether it’s indexed by Google, whether it’s even still online. None of that is independently re-checked; it’s trusted as reported.
WIRING UP THE ABILITY TO PUBLISH
A WordPress access credential is minted directly against the site’s own login and tested on the spot for manually-added sites. Sites imported in bulk often need this done by hand afterward, since the network rarely hands over working publishing credentials with the rest of the data.
WordPress REST API — Application Passwords
WHAT VOICE DOES A BACKLINK POST GET
Whatever gets published on that site is written using that site’s own client profile, not the money site’s brand. The catch: a site imported in bulk usually has no brand voice, audience, or value proposition ever filled in. So unless someone goes back and fills it in by hand, the writer quietly falls back to generic defaults: “general audience,” “educational and informative,” “professional, authoritative, and engaging.”
GETTING PICKED — BY A PERSON, OR AUTOMATICALLY
Building a campaign, a human explicitly chooses which backlink sites go into that run’s rotation. Separately, an always-on scheduler rotates through every backlink site on its own, always choosing whichever one has gone longest without being used, with a database lock ensuring two automatic runs can never grab the same site at the same moment.
pickRotationSite(‘backlink’) — FOR UPDATE SKIP LOCKED
BEHIND THE CURTAIN
Whether a site is labeled “Backlink” is really just a flag set at import time. A manually-added site defaults to an ordinary “Client” unless someone flips the toggle themselves.
The rotation queue isn’t a separate table anywhere; it’s one timestamp column on the site’s own record, read like a line where the oldest arrival goes next. And a “mention” campaign’s posts, if they happen to land on a different client’s domain, get counted and tracked as real backlinks too. The distinction is the domain, never the campaign’s label.
A brand-new article that says a client’s name — on purpose.
Worth stating plainly first: this isn’t a detector that scans the web for places a client is already mentioned. It’s the opposite: it manufactures a fresh mention, on demand, on a site the system already controls.
TWO TRIGGERS
Either a person builds a Mention Campaign naming a target brand, or the system starts one automatically, the instant any scheduled post actually goes live.
PICK A HOST SITE
The same pool of backlink sites is used here, but tracked on its own separate “last used for a mention” timestamp, so mentions and backlinks rotate through the same sites independently of each other.
WRITE AROUND THE NAME
The AI is asked for a topic that lets it mention the target brand naturally and positively, then the full article runs through the exact same writing pipeline as any other post, with one rule written directly into the instructions: never turn the brand’s name into a link.
TWO CLIENTS’ DATA, TWO DIFFERENT JOBS
The article is written in the host site’s own voice, usually the system’s generic defaults, since these are typically bulk-imported sites with no brand profile of their own. The brand actually being mentioned supplies a much narrower slice of information instead: just its name, industry angle, value proposition, and target keywords. That’s enough to describe it accurately, but none of its tone or forbidden-phrase rules, since it isn’t the one doing the talking.
A separate, slimmer mentionTarget object — no brandProfile
EXTRACTING THE EVIDENCE
Once the draft exists, a plain text scan (no AI involved this time) finds every sentence containing the brand’s name, keeps a little of the surrounding context, and holds onto up to ten of these snippets.
extractMentionContext()
BEHIND THE CURTAIN
Mentions and backlinks are close siblings sharing nearly all of the same machinery, the only real difference is one omitted hyperlink, but they run on very different clocks: a mention fires the moment it’s triggered, while a matching backlink has to wait for a companion Cloud Link page to finish deploying before there’s even an address to link to.
The data needed to show a client “here’s everywhere you’ve been mentioned” already exists in the database, but the campaign screen doesn’t call it yet. The collecting is ahead of the showing.
One keyword and one web address become a live page.
A short, AI-written page, copied onto six different hosts at once.
TWO INPUTS, ONE PENDING RECORD
A target keyword and the client’s real website address: typed in directly, or handed over automatically by a campaign that just finished. A database row is created immediately in a “pending” state, capped at twenty per campaign, and a background job is queued to do the actual work.
A FOCUSED PAGE, NOT A FULL POST
Not a full blog post: a tight 600 to 900 words, built from a short outline, using the same trusted-source link sourcing as everywhere else, ending in one call-to-action pointed back at the client’s site.
STILL THE CLIENT’S OWN VOICE, JUST SHORTER
Even though it’s a stripped-down page rather than a full post, the writer reads the exact same client profile as everything else: brand voice, value proposition, geographic market, target keywords. So a Cloud Link page reads as if it came from the money site itself, only condensed. When the client’s brand profile has an author link on file, the page’s structured data picks that up automatically.
ASSEMBLED BY HAND, SCRUBBED BEFORE IT GOES LIVE
The AI-written body, a machine-readable business listing built by ordinary code rather than the AI, and a small embedded map keyed to the keyword are stitched into one self-contained page, with every AI-produced piece scrubbed of any script or embedded code before it’s allowed to go anywhere near “live.” The finished page is written to the database first, so nothing is lost if a hosting provider fails partway through the next step.
DEPLOYED TO SIX HOSTS AT ONCE
If some hosts fail and others succeed, that still counts as a win: any address that comes back live is a live backlink.
Netlify
Cloudflare
GitHub
Neocities
Vercel
TOLD TO THE SEARCH ENGINES RIGHT AWAY
Every address that comes back live is immediately submitted for fast indexing, without waiting on anything else to finish first. And the manager view quietly checks in every eight seconds until every page in sight has either gone live or failed, then stops asking.
BEHIND THE CURTAIN
Only one of these pages is generated at a time, on purpose: a deliberate limit to keep the server from running out of memory, since it runs on comparatively cheap infrastructure.
Deleting the record in the app never takes the live pages down. That’s by design: the entire point is a permanent footprint of links pointing at the client’s site. And re-deploying the exact same page always lands back on the same one of several possible hosts, calculated from the record’s own ID, not chosen freshly each time.
A direct publish, an internal link, a cross-domain backlink, a link-free brand mention, or a page copied across six hosts: everything Blog Monkee builds points some kind of authority back at a client’s real website.
This is the same engine described on the Technology page, traced here down to the real function names and API calls, straight from the source.
Compiled from a direct reading of the Blog Monkee 3.5 source: packages/backend/src and packages/frontend.