Why Our Agency Published No Articles for Two Months

Our agency website had been live for roughly two months, but we had not published a single useful article. That was uncomfortable because we help other businesses with marketing, design, development, and ecommerce—and yet our own website was behaving like a brochure.

The problem was not that we had nothing to say. We regularly answer questions about websites, leads, content, proposals, client operations, and the tools service businesses use. The problem was the distance between having a useful answer and turning it into a finished page.

This is the postmortem of that failure and the publishing system we are building for Cora.

1. Why We Published Zero Posts

The old process began with a blank page and too many open tabs.

We had to decide what to write, search for the topic manually, collect useful references, prepare a draft in one tool, revise it somewhere else, and then move everything into WordPress. Publishing still required formatting headings, checking links, writing metadata, adding FAQs, choosing internal links, and making sure the page looked right.

None of those tasks is individually difficult. Together, they created enough friction that publishing was always postponed behind client delivery.

This distinction matters. Telling a busy agency founder to “be more consistent” does not fix a system that makes every article feel like a small website project.

2. The Workflow Was the Real Problem

Our website could display an article, but it did not help us create or operate the article.

The research context lived in one place. The draft lived in another. WordPress was the final destination, but it did not know the buyer question, the intended audience, the internal links we wanted, or what should happen after a reader became interested in Cora.

The workflow had five recurring failure points:

1. Research started from zero. We were searching broadly instead of beginning with questions already heard in conversations.
2. The draft crossed too many tools. Every transfer created formatting work and lost context.
3. SEO happened at the end. Titles, descriptions, links, and FAQs became an extra checklist after the writing was supposedly finished.
4. The page had no operating connection. Publishing and the post-enquiry client workflow were treated as separate systems.
5. There was no definition of done. Every article invited a new debate about structure, length, and presentation.

The lesson was simple: our content problem was an operations problem.

3. What We Built Instead

We created one reusable article structure inside the marketing-site repository. Every article now has a defined category, URL, title, description, author, dates, key takeaways, table of contents, body, FAQs, related pages, and next action.

When an article is added and the production build passes, the site automatically generates:

• The article at /articles/{category}/{slug}/.
• Its category page and article card.
• A canonical URL and social metadata.
• Article, breadcrumb, and FAQ structured data.
• Sitemap inclusion.
• Related-article links.

We also added a publishing check that catches missing canonicals, duplicate metadata, absent schema, blocked crawlers, missing sitemap entries, and risky absolute claims before a page is pushed.

This does not make the content useful by itself. It removes repeated publishing work so our attention can stay on whether the answer is honest, original, and helpful.

Google’s own guidance recommends helpful, reliable, people-first content and warns against generating many pages without adding value. That matches the system we want: use AI to accelerate research and structure, while keeping a human responsible for the experience, evidence, and final claims. See Google’s guidance on generative AI content.

4. Why We Did Not Add a CMS

A CMS may become useful later when non-technical contributors need independent editorial workflows, permissions, scheduled publishing, or a visual preview system.

At this stage it would also introduce another database, API, authentication layer, integration, and source of publishing failure. Our current team already works from the repository, so Git gives us version history, reviewable changes, predictable builds, and deployment through the same process as the rest of the website.

That tradeoff will not be right for every company. For us, the simplest system is the one we are most likely to use consistently.

5. Our New Publishing Rule

We are not committing to fifty generic articles. We are committing to answering one repeated buyer question at a time.

A new article must begin with evidence that the question matters: something we experienced ourselves, heard repeatedly in conversations, observed during onboarding, or found in real search and community data. If an existing page already answers the question, we improve that page rather than manufacture another keyword variation.

Our first cluster will focus on the problems we understand directly:

• WordPress and Elementor maintenance for agencies.
• Why agency websites stop publishing.
• What should happen after a visitor submits an enquiry.
• Why service businesses struggle to fit custom projects into WooCommerce.
• How website content connects to leads, proposals, documents, billing, and delivery.

The objective is not traffic at any cost. It is to become a useful source for the exact businesses Cora is being built to serve—and to learn from the questions that bring them to us.