How OpenRouter generated 49,139 organic clicks from technical content in three months

Key outcomes

• 39 active articles received 49,139 organic clicks and 4.36 million search impressions in three months.
• Forty articles received 6,025 visits from AI assistants between June 20 and September 19.
• Hackmamba produced 74 technical articles through the content program.
• Twenty-two tutorials recorded a 1.34% average CTR at an average search position near six.

Company snapshot

• Industry: AI infrastructure / developer tools
• Company Size: 11–50 employees
• Location: New York, United States
• Use Case: Technical content, SEO, AEO, and editorial production
• Product: AI gateway and unified API for accessing and routing across models from multiple AI providers.

The challenge

OpenRouter wanted to publish more technical content for developers and improve its visibility across search engines and AI assistants. The team had already built Shakespeare to research topics, prepare briefs, and generate first drafts.

When we reviewed an early batch of Shakespeare-generated drafts, we found that some of the product information in its knowledge base no longer matched OpenRouter's live product.

One company profile draft stated that OpenRouter had 2.5 million users when the verified figure had already passed 5 million. Another draft described a 5% markup that OpenRouter no longer charged. Three of the five topic drafts we reviewed stated that OpenRouter lacked SOC 2 even though the company held a Type 2 report.

The drafts also needed more technical judgment before publication. Writers had to determine which details mattered to developers, verify claims against current documentation, test technical examples, and make recommendations that the available evidence supported.

Kenny Rogers, DevRel Lead at OpenRouter, described the challenge:

OpenRouter needed a production process that could take Shakespeare's output through technical and editorial revi

Our approach

We took over after Shakespeare produced the first draft. We gave writers ownership of technical verification and testing, added separate review stages, and organized production into monthly batches.

1. We checked product claims against current documentation

OpenRouter operates in a market where model prices, context limits, parameters, endpoints, and supported capabilities change frequently. Writers checked relevant product information on the day they worked on each article.

They used OpenRouter's live model pages, endpoint lists, and documentation to verify product claims. When an article covered a model from another provider, writers also checked the provider's documentation for details such as model slugs, prices, supported parameters, context limits, and API capabilities.

When reliable sources disagreed, writers removed the claim or flagged it for review. During one article, for example, a writer found two different figures for an Artificial Analysis score and left the figure out because it could not be verified confidently.

Each article included a review guide that documented the claims checked, sources used, corrections made during production, and questions that still required OpenRouter's input. OpenRouter's reviewers could see how a technical claim had been verified when the article reached them.

2. We ran the workflows described in technical tutorials

Writers tested the workflows they asked developers to follow. They executed commands, ran code samples, configured integrations, and recorded the results.

One tutorial required a test harness in Python, TypeScript, and Bash. The writer ran all six examples end to end against a local mock and then tested the TypeScript implementation against OpenRouter's live API across 100 requests.

The article reported the results from those tests and documented the limits of the experiment, including its use of synthetic data and the absence of a same-effort comparison. The accompanying review guide recorded how the tests were run and where the results came from.

This process gave reviewers evidence they could inspect and gave developers examples that had been executed before publication.

3. We gave each production stage a specific owner

Shakespeare handled topic research, briefs, and first drafts. Those drafts then entered Boki, where a team of eight writers worked across the OpenRouter account.

The writer verified product claims, developed the article, ran relevant technical workflows, and added recommendations supported by research and testing. The article then went through two review agents.

The technical review agent checked code, API parameters, and product claims. The marketing review agent checked sources, structure, product context, and statements that could give readers an inaccurate understanding of the product.

Writers reviewed every finding and decided which changes the evidence supported. A human reviewer then checked the article for technical depth, clarity, repetition, and writing quality before we sent it to OpenRouter.

We also tested AI detectors while developing the review process. A piece written entirely by a person received an AI probability score above 90%, which made the score unsuitable for our editorial process.

Our reviewers documented recurring writing problems as they found them. Those observations became an editorial checklist and informed the review rules inside Boki. The checklist covered unsupported claims, inflated language, repeated explanations, shallow technical sections, and generic summaries that did not help developers solve the problem covered by the article.

4. We organized production into monthly batches

Moving 74 articles through writing, verification, and review required a production schedule that kept work moving without sending dozens of unfinished drafts to OpenRouter.

We organized the articles into monthly batches. Writers could develop an upcoming batch while we reviewed another and OpenRouter approved a completed batch.

We completed the technical and editorial reviews before delivery. OpenRouter's team received finished articles and could spend its time on final product questions and approvals.

The batch structure also gave writers time to resolve questions through documentation, testing, and internal review. Questions that reached OpenRouter were generally the ones that required direct product knowledge.

5. We added search data to OpenRouter's topic process

OpenRouter selected the 74 topics through its existing research process. Shakespeare combined keyword opportunities, gaps in AI-answer visibility, gaps in OpenRouter's existing content, and topics gaining attention among developers.

The OpenRouter team also contributed topics from conversations with developers, startups, and enterprise customers. We reviewed the search opportunity before drafting each article.

We checked the primary keyword in Ahrefs for search volume and difficulty and reviewed OpenRouter's published content for overlapping search intent. These checks helped identify potential overlap and weak search opportunities before writers committed production time.

As articles went live, their performance became another input for planning future batches.

Results

1. Four practical guides accounted for 70% of organic clicks

Four guides received 34,390 organic clicks: Free LLM APIs Compared, Any Coding Agent, Claude Code, and Codex CLI. That figure represents 70% of clicks across the measured set after rounding.

The format breakdown gave us another result to use in future batches. The 22 tutorials recorded a 1.34% average CTR, while the 17 explainers recorded 0.60%. Both groups held average search positions near six.

2. Engagement varied across article types

The Zero Data Retention and Prompt Caching articles recorded the longest engagement times among the examples in this dataset. Tutorials with commands and configuration fell within a 28 to 37 second range

3. Developer queries produced specific search wins

Searchers clicked the Zero Data Retention article 164 times in its first 10 days, and Google placed it between positions two and four for searches related to "OpenRouter ZDR."

Google placed the team-spend article first for "OpenRouter BAA." The image-generation article recorded a 66.7% CTR for the exact query no endpoints found that support image input.

These queries give OpenRouter concrete examples of the product questions and technical problems developers search for.

4. AI assistants sent 3,725 visits in August

AI assistants sent close to 165 visits per month to OpenRouter's blog content before the new articles began publishing. That number reached 2,391 in July and 3,725 in August.

Hackmamba-produced articles accounted for 70% of July's AI-assistant traffic and 62% of August's.

The source breakdown for the measurement period contains 6,024 visits attributed to named assistants.

The Free LLM APIs comparison received 2,717 visits from AI assistants, including 754 visits from Gemini.

Ongoing engagement

We continue to work with OpenRouter on new content batches. As OpenRouter prepares each batch, we review query-level search data, CTR, engagement time, and AI-assistant referrals from published articles. We use those signals to validate the proposed topics, flag overlap or weak search opportunities, and identify where a brief should go deeper into a specific product capability, workflow, integration, or developer problem.

OpenRouter continues to own topic selection and final approval. We use the performance data to improve the briefs and shape how each article is approached before it moves into production. OpenRouter has also implemented technical and on-page SEO recommendations from us during the engagement.

The published articles now give both teams a clearer view of what developers search for, which formats earn clicks, and which pages AI assistants surface. We use that information to make each new batch more focused than the last.

If you are a devtool company looking to start a technical content program, or you already have one and want to hand over production, technical review, and SEO to a team that can run it with you, book a call with Hackmamba.