Inside Paul Ryazanov’s Ecommerce Knowledge Base

Most founders sit on a decade of content and never use it twice. Paul Ryazanov had 340-plus posts and pages, 245 LinkedIn updates, and 46 recorded talks scattered across the web, each one written once and forgotten. We pulled all of it into a single structured knowledge base, mapped what it contains, and now use it to repurpose his existing content into new articles on his site. This article is the map: what is in the knowledge base, the nine clusters of expertise it reveals, and why that matters for how Google and AI assistants understand him.

Paul is the co-founder and CEO of MageCloud Agency, a 50-plus person team across the UK, Denmark, and Ukraine that has built seven-figure ecommerce stores for over a decade. He founded Ecommerce Camp UK, mentors at GrowthMentor, and has spoken at PubCon, BrightonSEO, MeetMagento, and Conversion Conference since 2012. That is a real entity with 20-plus years of operator experience. The problem was that none of it was organized in a way a machine could read.

What the knowledge base actually contains

A knowledge base is only useful if it is complete and structured. Before any writing happens, every public thing the founder has produced gets gathered in one place and inventoried. For Paul that meant the full website downloaded page by page, every LinkedIn post exported and catalogued, and every YouTube talk transcribed so the words are searchable text rather than locked inside video.

The point of the count is not the count. It is that a machine now has one place to look. When an AI agent needs to know what Paul thinks about hosting, or how he describes his no-contract agency model, or which platforms he has migrated stores between, the answer is in the corpus in his own words. The corpus is the difference between a tool guessing what a founder might say and a tool quoting what he actually said.

None of that arrives clean. The site came through its own API as 720 raw source files before it was inventoried down to the 340-plus posts and pages that are genuinely his. The LinkedIn archive exported as a dump of roughly 1,959 items, which is where the 245 real posts were pulled from. Every talk was transcribed one at a time so the spoken words became searchable text rather than audio nobody can query. Only then was the voice profile derived, from four transcripts and five shipped articles, and the nine clusters below were read out of the corpus rather than guessed at.

The nine clusters that reveal his expertise

Read across the whole corpus and a shape appears. Paul does not write about everything. He writes, consistently, about nine things. Those nine clusters are his topic wheel, and each one is a claim of authority that Google can attach to the entity.

Two of the nine are his strongest and least contested. Agency operations and business model is the cluster almost no other agency publishes, because Paul runs a 50-plus person agency with no contracts, no retainers, and direct founder communication, and he explains exactly how. That shows up in pieces like how the agency earns trust without contracts or retainers and three-year client retention with no contract holding anyone there. CRO and A/B testing is his longest-running speaking topic, running from a PubCon landing-page talk in 2012 through a 300 percent-lift conversion talk in 2015, which is 13 years of credible depth.

The rest of the wheel is just as concrete: platform selection and migration across Magento, Shopify, and WooCommerce; ecommerce hosting and infrastructure, which he can write from both the vendor and the operator side because he co-founded a hosting platform and an agency; technical SEO and site security as a single integrated practice, which was the thesis of his BrightonSEO talk on scaling bottlenecks; the founder and immigrant-founder journey, which is his identity signal; ecommerce events and community through Ecommerce Camp; ecommerce careers; and the emerging cluster of AI in ecommerce. His framework for high-converting stores, the COMERIX conversion framework, sits across several of these.

The analysis is the value here. A scattered founder looks like a generalist. A mapped founder looks like a specialist with nine named areas of depth, and specialists are what Google commits to and what AI assistants recommend.

How the corpus turns into published content

The knowledge base is not an archive. It is the input to a pipeline. From the raw corpus we derive a voice profile, a set of article guidelines, the topic wheel above, and the entity and bio facts. Directed AI agents then read a source post, rewrite it into a full article in Paul’s actual voice, interlink it to the rest of his library, set the SEO, and publish it under his byline. More than 170 articles have gone out this way.

Because the voice profile was built from real transcripts and shipped articles, the output reads like Paul, not like a chatbot. Because the topic wheel is explicit, each new piece deepens a named cluster instead of adding noise. This is the Content Factory loop applied to one person, and the full build behind it is documented in how we built this knowledge base with a Claude agent.

The knowledge base this actually lives in

Paul’s corpus is not a standalone project. It is one entity inside a single Obsidian vault that holds everything we do, and the vault is the reason any of it compounds instead of evaporating when the engagement ends.

The bottom layer is the entity knowledge bases: one folder per person or brand, each holding its raw sources, its compiled truth, and its deliverables. Paul is one of them, sitting next to Cody Jones, WebinarJam, Dunkademics and the rest. The 720 source files, the LinkedIn export, the transcripts, the voice profile, the topic wheel: all of it lands there rather than in somebody’s downloads folder.

Above that sit the skills and SOPs, the reusable procedures. How to build a knowledge base. How to publish it. How to QA an article. How to repurpose a talk into a written piece. They are routed by task, so an agent picks up the right procedure instead of improvising a new one each time.

At the top is the canon: the frameworks that hold no matter whose name is on the folder. The Nine Triangles, the Content Factory, the topic wheel, the entity linking decision tree, and the standing rule that you always boil the ocean rather than settle for good enough.

The part that makes it improve itself

Paul’s build matters to more than Paul, because it was the first full run of this system end to end.

Writing it up is what produced the procedure. The knowledge-base publishing skill, the three-article pattern, the interlinking convention, the rule that the third-party map and the first-person companion must never be the same words: all of that came out of doing it here first and then documenting exactly what worked. Cody Jones ran on that procedure. WebinarJam ran on it after Cody’s review sharpened it. Dunkademics ran on it after WebinarJam’s accuracy work sharpened it again. None of them started from zero, because this one did.

The loop runs every time. Do the work. Document the run honestly, including what broke. QA it against what the procedure promised, and flag every place the agent had to guess, because a guess is a missing instruction. Fix the procedure so the next run does not need to guess. Then push whatever is general enough to help anyone into BlitzBase, the distributable version of the vault, scrubbed of every client name. If the lesson cannot be stated without naming a client, it was never general, and it stays put.

Dennis Yu calls this RSI, recursive self-improvement, and it is the whole reason the library gets sharper instead of going stale. It is the same idea behind the task library: one page per task, one URL per page, and every run makes the page better. The documentation is the asset. A shelf of one-off projects rots. A library that rewrites itself compounds, and keeping it current is the work.

What went in, what it cost, and what it would have cost

The ingestion inventory, so the numbers are checkable rather than atmospheric:

• The site pulled through its own API: 720 raw source files, inventoried down to the 340-plus posts and pages that are genuinely his
• The LinkedIn archive exported: roughly 1,959 items, narrowed to 245 real posts
• 46 recorded talks transcribed, so the spoken words became searchable text
• A voice profile derived from four transcripts and five shipped articles
• A nine-cluster topic wheel read out of the corpus rather than guessed at
• More than 170 articles published from the base since

The agent column is a list-rate estimate, priced at published API rates for the Opus-class model that did the work, roughly five dollars per million input tokens and twenty-five per million output. In practice these runs happen on a flat-rate plan, where the real marginal cost is a fraction of the list figure, so read that column as an honest worst case rather than a bill. The human column is a blended fifty dollars an hour, sitting between the thirty-five an hour a working digital marketer costs and the seventy-five to a hundred and twenty-five an hour a senior strategist costs. On those numbers the base came in roughly seventy times cheaper and about eleven times faster.

And the base is the smaller line. The 170-plus articles published from it are the bigger one. A researched, voiced, SEO-set article takes a competent human two and a half to four hours, so that library is on the order of 510 human-hours and more than twenty-five thousand dollars. Run as agent work at the house benchmark for a full article, it is roughly 23 agent-hours and under fifty dollars at list rate. That is the whole argument: the base is what makes every article after it cheap.

What the agent did, and what still needed a human

The agent handled: pulling the site through its API and reconciling it, exporting and cataloguing the LinkedIn archive, transcribing the talks, deriving the voice profile from real transcripts rather than inventing one, reading the nine clusters out of the corpus, drafting each article in Paul’s actual voice, interlinking it into the existing library, setting the SEO, publishing under his byline, and grading its own output against the checklist.

A human was still required for: Paul himself, who is the only source of the expertise the corpus is made of. The relationship and the approvals. The strategic calls about what gets published and what does not. Factual corrections that only he can make. And inspection, which is now the durable skill, because an agent that grades its own high-stakes work will eventually pass something it should have failed. The human job moved from production to catching the bad output before it ships.

Why this is worth doing

For Paul: a decade of writing stops being used once and thrown away. The entity consolidates, so a search for his name returns him and his work rather than a stranger who shares it, and an AI assistant answers factually instead of guessing. His site keeps growing from material he had already produced. That is an owned asset, not rented reach.

For BlitzMetrics: this was the first full run of the system, and the first run pays for the procedure. Writing it up produced the knowledge-base publishing playbook that Cody Jones, WebinarJam and Dunkademics all ran on afterwards, each of them starting where this one ended. That is the actual product: not one article and not one site, but a library of documented procedures that sharpens every time it runs, and that anyone can install as BlitzBase.

Why a structured knowledge base strengthens the entity

Search engines and AI assistants commit to an entity when enough corroborated signal points to the same person saying the same things in the same areas. A knowledge base is how you produce that signal on purpose. Every article deepens a cluster, every cluster corroborates the entity, and the whole library cross-links back to the source. This is the mechanic Dennis Yu lays out in Google Entities and Trust and in owning your name on Google.

For a founder about to appear on more stages, sign more partners, and field more press, a consolidated entity is money. It is the reason a search for his name returns him and his work rather than a stranger with the same name, and the reason an AI assistant gives a factual answer when someone asks who he is.

If you want to see the living result, Paul’s site is the deliverable, and it keeps compounding from work he had already done. If you want the full engineering of how the knowledge base was gathered, structured, and published, read the build write-up. The same system runs for founders and brands who have produced real work and want it to compound instead of disappear, from Cody Jones to WebinarJam to Dunkademics.