Build a tool or calculator site

What a tool site is, and why tool pages work

A tool site answers a query by doing the thing rather than describing it. A unit converter, a mortgage calculator, a colour palette generator, a file converter. The searcher's intent is transactional in a way an article cannot satisfy: someone who types "convert PDF to Word" does not want to read about it.

The traffic available is real and it is measurable. Ahrefs' analysis of 16 July 2026 gives US organic figures for a set of named sites and pages:

The last row is the most useful, because it is first-party and dated: Ahrefs launched that subfolder in mid-2023, watched it peak near a million monthly US visits, and reports it now sitting in the hundreds of thousands. That decline is as informative as the peak. Tool traffic is not permanent and it is not passive.

Why tool pages attract links

The strategic argument for tools is not really about traffic. It is about links, and the mechanism is simple: a tool is useful to a writer's reader. A journalist covering mortgage rates will link to a mortgage calculator so their audience can run their own numbers. That same journalist will not link to your mortgage blog post, because it competes with the article they are writing.

Search Engine Journal's guide to earning links with free tools names five long-running examples: WordCounter, which has been running since 2008; Tire Size Calculator; How Much to Make an App; the New York Times rent-versus-buy calculator; and Siege Media's embed code generator. It reports that links typically start appearing "after 2 months onwards" and accumulate over years. (source)

Two caveats belong with that. The guide was published in 2019, so treat the pattern and the examples as durable and the timing as indicative rather than current. And it publishes no backlink counts for any of the five named tools, so the strength of the effect is asserted rather than measured.

Build it client-side first

The single most consequential decision is where the tool runs. A calculator whose maths executes entirely in the visitor's browser has no server cost, no API key to leak, no rate limit, no vendor that can go out of business, and it works from a static host. For anything that is arithmetic, unit conversion, formatting or generation, that is overwhelmingly the right default.

A server is genuinely required in only four cases: the tool needs data you cannot ship to the browser, it calls a third-party API with a secret key, it does heavy computation, or it has to persist something between visits. Everything else is a preference, and the preference costs money and fragility.

Keeping an API key off the browser

If a tool does call a paid third-party API, the key must never appear in client-side JavaScript. Anything in the browser bundle or visible in a network request is public — "obfuscated" is not "private". The standard pattern is a thin server-side proxy endpoint that holds the key in an environment variable, applies rate limiting and origin checks, and forwards only sanitised requests. Without the rate limiting, a public proxy is a bill waiting to happen. This is established practice rather than a rule anyone publishes; check your API provider's own security documentation before launch.

API dependency is the risk that matters most for a small operator. Any tool built on someone else's API inherits their pricing changes, rate limits, deprecations and outages. A tool built on pure client-side logic inherits none of them. The tool that depends on nobody is the tool that still works in five years.

What it costs to build in 2026, and why that is not the advantage

Ahrefs reported in July 2026 that producing a working calculator with AI assistance costs around $1.24 and takes minutes, eliminating the need for developer resources. (source)

Read that critically before it becomes a business plan. Two things are true about it. The first is that it is a single vendor's figure, published by a company that sells software to SEOs and therefore has an interest in the strategy sounding easy. The second, and more important: if a calculator costs you $1.24 to build, it costs your competitors $1.24 too.

Nothing that cheap is a moat. The build was never the hard part of this strategy, and now that it is nearly free, the scarce things are the ones that were always scarce — distribution, links, and being the version people already trust and already link to. WordCounter's advantage is not its code. It is seventeen years of accumulated links and habit. Cheap tooling lowers the barrier to entry for everyone simultaneously, which raises the value of everything that cannot be generated in minutes.

Maintenance: what actually breaks

Tools are not build-once assets. The failure modes are predictable, which means they are avoidable:

• API changes and deprecations. The largest ongoing risk for any tool with an external dependency, and the reason to avoid one where the maths allows.
• Stale data. Tax rates, interest rates, postage rates, conversion factors, regulatory thresholds. A calculator returning last year's numbers is worse than no calculator — it is a trust problem, and in regulated verticals a liability problem.
• Framework churn. A tool built on a JavaScript framework needs dependency updates or it eventually stops building at all.
• Abuse and cost. Public endpoints get scraped and hammered. Rate limiting is not optional.
• Mobile and accessibility. A calculator that does not work properly on a phone loses most of its traffic before it earns any.

The design-time fix for most of this is the same: keep the tool self-contained, and date any reference figures it depends on so a visitor can see when they were last checked.

Tools and AI search

The argument that tools are defensible against AI answer engines is coherent, and it is an argument rather than a measurement. Ahrefs puts it as: AI Overviews can describe how to convert a file, but they cannot hand the user the working converter. (source) That is a claim about intent — an answer engine substitutes for an explanation far more easily than it substitutes for an interaction — and Ahrefs presents it as reasoning, not as citation data.

There is a finding that cuts the other way. The largest citation dataset located, OtterlyAI's analysis of over a million citations in January and February 2026, does not segment by page type in a way that isolates tools, but it does identify JavaScript rendering as a barrier to citation — which is a direct negative for a heavily client-side tool page. (source)

So the honest position is: tools are plausibly more resistant to answer substitution than explanatory content, no published study measures tool-page citation rates in AI search, and the one adjacent finding is unfavourable. Do not build a strategy on tools being "AI-proof". Do render the explanatory content around the tool as server-side HTML.

Resale, inquiries, and when a tool site is the wrong call

A working tool with traffic is a product, and it is bought and sold as one — on revenue or traffic multiples rather than on the name above the door. The diligence is unusually easy: a buyer can verify the asset in thirty seconds by using it. The offsetting problem is that the buyer also inherits the maintenance obligation and every API dependency, which narrows the pool to people who can operate it. No published multiples data for small tool-site sales exists, so treat any valuation rule of thumb you are offered as opinion.

One combination to avoid: a tool site on an exact match domain is an awkward hybrid. Name buyers do not want the code, and product buyers do not care about the name.

The strategy is the wrong call when the vertical's queries are informational and comparative rather than transactional; when there is no discrete calculable job to be done; when the calculation depends on data you would have to license or maintain expensively; when the space is already consolidated, as the generic calculator space largely is around Omni Calculator's ~2.3M monthly visits; or when you cannot commit to maintenance. It is also the wrong call if the plan is one calculator on one domain. The sites in Ahrefs' list that scaled did so across many tool pages plus supporting content. A single calculator is a page, not a business.

Common mistakes

• Building on a third-party API with no fallback and no cost ceiling. The vendor changes their pricing and your unit economics change with it.
• Shipping an API key in client-side code. It is public the moment it loads.
• One tool on a domain, with no supporting pages and no plan for the rest of the topic.
• Never updating the underlying rates or data, until the tool quietly starts giving wrong answers.
• Rendering the tool and all its explanatory content in JavaScript, so crawlers and AI retrievers see an empty page — the citation barrier OtterlyAI identifies.
• Assuming cheap to build means easy to rank. These are unrelated properties.
• No explanatory content around the tool, so there is nothing for a link or a citation to point at and nothing to establish that the maths is trustworthy.

The pattern running through all seven is the same. The code is the cheapest and least defensible part of a tool site. Everything that makes one work — the maintenance, the explanation, the breadth of coverage, the accumulated links — is the part that cannot be generated in minutes.

Frequently asked questions