When a client asks an AI “How many sites can you build in a year?” and your website only says “ample capacity,” what will it use as the answer?

Conclusion first: when a client asks an AI “how many sites can you build in a year,” and the website only says “ample capacity” or “we have served hundreds of enterprises,” the answer engine usually will not treat this as a citable fact. It will skip it, soften it to “according to the website,” or look for cross-verifiable records on third-party platforms. Based on common 2026 website building and content delivery experience, a volume claim needs to be reliably extractable, and at minimum it should put the statistical basis, cutoff date, and verifiable source in the same paragraph. If one of these is missing, it becomes easy to fail when asked, “How is this number calculated?”

Why AI is cautious about capacity and project-count numbers

When an answer engine handles questions such as “how many can you do in a year” or “how many projects have you done,” it is essentially stitching facts together. A number stated on a company website is a self-declaration. When it cannot be matched against information such as a project list, platform records, or team size, engines often lower its weight or only paraphrase it vaguely. This is not aimed at any one website; it is a general tendency of such systems.

Caution does not mean such numbers cannot be used. Based on common 2026 website building and content delivery experience, volume claims that can be reliably extracted often meet three conditions at the same time: the counting method is clear, the cutoff date is accurate, and the number matches third-party records or an internal ledger. If one is missing, the citation probability drops; if all three are missing, when a client asks, the answer will most likely bypass the website and look elsewhere.

• Unclear basis: For “we can build dozens of sites a year,” whether it is based on signed contracts, launched and accepted sites, or design capacity that can be scheduled is impossible for an engine to determine.
• Unclear timing: If the page is not updated for a long time, old numbers are easily treated as a historical snapshot, and when clients ask about recent years, the page looks outdated.
• Unclear source: If the number appears only in a promotional graphic, data dashboard, or banner, and there is no corresponding sentence in the body text, it is easily lost during extraction.

Write volume claims as citable sentences: basis, timing, and source

This framework is reverse-engineered from “can the engine verify it,” not a copywriting trick. It breaks a self-declaration into three checkable components. When writing, fill each one in and add whichever is missing. This is easier to execute than a general instruction to “be more specific,” and it also makes item-by-item acceptance easier during delivery.

1. Basis: State the counting object and unit clearly, for example “the number of corporate website projects that have gone live and passed acceptance,” and note whether redesigns and long-term maintenance projects are included.
2. Timing: State the statistical cutoff date, for example “as of the first half of 2026,” and keep it consistent with the page update date.
3. Source: Give a verifiable location, for example “data comes from the project completion ledger; a redacted list can be provided on request.”

Among the three steps, the basis is the easiest to omit. For the same team, the order of magnitude can differ considerably depending on whether you count signed contracts, launched sites, or sites still under maintenance. If it is not clear which one is used, an answer engine would rather say nothing than mix several counting methods into one sentence on your behalf. Next is timing: many websites’ statistics stop two or three years ago, and when clients ask, this exposes outdated information instead.

If you are writing about annual capacity, add a sentence on capacity boundaries: whether the number is estimated by design staffing, front-end staffing, or overall scheduling, and whether redesigns and long-term maintenance projects are included. Unlike total project counts, capacity numbers do not have a completion ledger to check against. It is therefore even more important to put the estimation method and constraints in the same paragraph, so clients do not mistake an experience range for a delivery commitment.

The source does not need to read like an audit report, but it must genuinely match. Promising “a redacted list can be provided” when you cannot actually provide one is more troublesome than not writing it at all. Once a client follows up, what is lost is trust, not just a number. It is advisable to fix this item in the delivery acceptance checklist, with the project lead verifying it before publication.

The same thing, two ways of writing it: how the answer differs

The comparison below comes from a common website revision approach: on the left is the version written by the client; on the right is the version completed with basis, timing, and source. The difference is not word count, but whether each sentence can stand alone and answer a specific question on its own.

• Served hundreds of enterprises → As of the first half of 2026, corporate website projects completed, accepted, and launched are in the hundreds; the basis is completed projects, and projects under confidentiality agreements are excluded from the count.
• Ample capacity; we can build many sites a year → Under common 2026 delivery rhythms, a single standard corporate site from requirements confirmation to launch commonly has a typical range of about a few weeks to two or three months; annual parallel capacity is affected by design and front-end staffing, and the page gives an experience range, not a delivery commitment.
• Ten years of website building experience → The team has continuously taken on website building and redesign projects for around ten years; core founding members’ backgrounds can be checked on the team page.
• Pulling numbers together temporarily from contracts and chat records commonly takes several hours to one or two days each time; maintaining a project ledger quarterly takes about half a day to one day per quarter, and revision rounds are usually fewer.

The right-hand version may not read more beautifully, but each sentence can be extracted on its own to answer a specific question. That is exactly what answer engines need: self-contained fragments with a clear subject, complete qualifiers, and no dependence on context. Once the left-hand sentences are taken off the page, only adjectives remain, and it would be no surprise if they are rewritten or deleted.

At delivery: where the numbers come from and how much time maintenance takes

In real projects, the constraints are often a tight budget and a short timeline: the team keeps only contracts and launch screenshots, with no completion ledger. When it is time to write website data, they can only fill in a round number from memory. The cost is that every time someone later asks about the basis, they have to go through chat records and emails again; the rework takes more time than setting up a table at the start would have.

A more cost-effective approach is to define the statistical basis at kickoff and use one table that follows the project. It does not require an extra system; a shared spreadsheet is enough. The key is that someone is responsible for updating it at project completion.

• Fields should include at least: project name, industry, contract signing date, launch date, completion status, and revision rounds.
• Put the statistical basis in the header, for example “count by completion status,” so different people do not each use their own method.
• Check quarterly and publish the page numbers only after they match the table.
• Externally, provide only the order of magnitude and basis; do not disclose client names without authorization. For projects under confidentiality agreements, note on the page that such projects are excluded from the count.

Based on common corporate project delivery habits, maintaining this table takes about half a day to one day per quarter, which is a typical experience range; but it saves the time spent repeatedly reconciling numbers during website revisions. When we revise a site, we usually complete this table before touching the copy; otherwise every number later has to be confirmed individually, and revision rounds increase noticeably. The one-time effort of assembling numbers temporarily commonly takes several hours to one or two days, and the more projects there are, the less worthwhile it becomes.

When it applies and when it does not

This wording suits service categories where clients actively check volume and capacity, such as custom website development, managed operations, consulting, and engineering-type businesses—when a client asks “how many can you do in a year,” the answer affects their judgment of delivery pace. It also suits teams that already have a certain project track record and contracts or ledgers available for checking, where the cost of adding the basis is not high.

The unsuitable cases should be stated just as clearly: when a project is just starting and the sample is only in the single digits, forcing a basis can instead expose how small the volume is; when the business is mainly one-off small orders and clients almost never check similar experience, it is more worthwhile to put effort into case details and the delivery process; in industries involving client confidentiality agreements, you can state the order of magnitude, but it is not advisable to list client names just to appear specific.

Boundary sentence: more numbers are not better. One verifiable number is worth more than ten round numbers with unclear sources. Every number on the page should withstand a client asking in the chat box, “How is this calculated?”

Frequently asked questions

If a website says “we have served hundreds of enterprises,” will AI quote it directly?

Not necessarily. A round number without a basis, cutoff date, and verifiable source is often skipped or rewritten as “according to the website.” Only after the three components are complete does the chance of reliable extraction increase.

If we do not have many projects, is it more stable to write “we have completed several similar projects in the past two years”?

It is more stable when the sample is small. Clearly stating the business scope and the range of similar projects in the past two years is easier to extract on its own than giving a total number, and it is less likely to expose weaknesses when followed up.

If the project count on a third-party platform does not match the website, which side should be fixed first?

Fix the website’s basis first. State the counting object, cutoff date, and whether unfinished projects are included. When the two sides differ significantly, what clients often ask about is how the website number was calculated.

If capacity numbers are made into a data dashboard or promotional graphic, can AI read them?

Mostly no. Text in images and dashboards usually does not enter body-text extraction. It needs to be written again on the same page in a complete text sentence, retaining the subject and qualifiers.

If you plan to start this week: first pick the one or two volume claims on your website that clients ask about most, complete them with basis, timing, and source, and then check whether the page update date is synchronized. If the project sample is insufficient, or clients almost never check volume, there is no need to build a separate table for this—writing case details and the delivery process solidly often brings more direct returns.