How to Write a Government Website RFP (Checklist + Template)

A government website RFP has one job: get you comparable proposals from vendors who understand what you are actually buying. Most fall short of that, not because the people writing them lack skill, but because the document was adapted from a construction or software template that was never meant to describe a website. The result is a stack of bids that price different things, and an evaluation committee forced to compare a $40,000 proposal against a $180,000 one without knowing which included content migration.

This is a checklist for writing the document, drawn from reading solicitations on the vendor side. If you are drafting one now, our general website RFP template covers the standard sections; this piece covers what changes when the buyer is a public agency.

Start with the problem, not the deliverable

The strongest solicitations open with a paragraph describing what is going wrong: residents call because they cannot find the permit form, the site fails an accessibility review, the CMS is out of support, three departments publish contradictory hours. That paragraph does more work than ten pages of feature requirements, because it lets a competent vendor propose an approach rather than just price a list.

Feature lists have the opposite effect. "Must include a photo gallery, an events calendar and a staff directory" tells a vendor nothing about whether your calendar problem is a software problem or a governance problem, and it invites everyone to bid the cheapest possible version of each item.

Define the scope tightly enough that bids are comparable

This is the single highest-leverage thing you can do. If one vendor includes content migration and another assumes you will do it, the prices are not comparable and the low bid wins for the wrong reason. Ask every respondent to price the same defined line items separately:

Discovery and information architecture. Design. Development and CMS build. Content migration, with a stated number of pages. Content writing, if you want any. Accessibility testing and remediation. Training. Post-launch support, with a stated duration. Hosting, if it is in scope.

Listing those as separate line items also protects you later. When the budget gets cut, you can drop a line rather than reopen the whole procurement.

Say how many pages you have, and how you counted

Page count is the number vendors need most and the one most often missing. Without it, everyone guesses, and the guesses vary by an order of magnitude. Run a crawl of your current site and state the number, along with how many are documents rather than pages. If you have 400 pages and 3,000 PDFs, say so — the PDFs are frequently the larger part of the work.

State what happens to the old content, too. Migrating everything, migrating a curated subset, or archiving and starting fresh are three very different projects.

Name the accessibility standard and say how it will be verified

Nearly every public-sector solicitation mentions accessibility. Most stop at "must be ADA compliant," which is not a technical standard and cannot be tested against. Name the standard — WCAG 2.2 AA is the current sensible baseline, and it clears the Section 508 bar that federal funding conditions usually import.

Then ask how conformance will be verified, and score the answer. A serious response names automated testing across the site plus manual keyboard and screen-reader passes on key journeys, and describes what documentation you receive. A vendor who answers "we follow accessibility best practices" has told you nothing. If you want a conformance report or VPAT as a deliverable, say so in the RFP rather than asking for it after award, so the testing that produces it is planned in.

Make URL preservation an explicit requirement

Public agencies carry an archive: agendas, minutes, notices, budgets, grant materials, sometimes decades of them. A redesign that moves every URL breaks all of that at once — a public-records problem and the fastest way to lose whatever search visibility the site had.

Write it in as a requirement: every existing URL must resolve after launch, either at the same address or via a permanent redirect, with a mapping document delivered before go-live. It is unremarkable work when planned and expensive when discovered late.

Describe your governance, honestly

Tell vendors how many people will publish and how technical they are. A site maintained by one communications officer and a site maintained by forty departmental editors are different builds, and the difference is not cosmetic — it drives the editing model, the permissions structure and the training scope.

If your last site failed because nobody could update it after the vendor left, write that down. It is the most useful sentence in most solicitations, and it tells a good vendor exactly what to design for.

Publish the evaluation criteria and the weights

If price is 40% and technical approach is 30%, say so. Vendors write to the rubric, and publishing it produces more responsive proposals for the same effort. Hidden weighting mostly produces guesswork, and guesswork favours whoever has bid to your agency before rather than whoever is the best fit.

Be realistic about how price is scored, too. A pure lowest-price-wins formula on a website project reliably selects the vendor who understood the scope least.

Set a timeline a good vendor can meet

Two weeks between release and submission is common and mostly self-defeating: the vendors who can turn a proposal around that fast are the ones using a template, and the ones you actually want are already committed for that fortnight. Three to four weeks gets you better responses at no cost to you.

State your target launch date and any hard constraints — a fiscal year end, a grant deadline, an election, a school year. A vendor who knows the constraint can tell you honestly whether it is achievable. One who does not will agree to it and renegotiate later.

Say whether questions are allowed, and answer them in public

A Q&A window with answers issued as an addendum to all respondents is the cheapest quality improvement available to you. Most clarifying questions reveal genuine ambiguity in the document, and answering them publicly improves every proposal at once.

State ownership and post-launch terms up front

Say who owns the code, the content and the accounts at the end, and whether ongoing maintenance is in scope or a separate procurement. Ambiguity here is how agencies end up locked into a proprietary CMS they cannot leave without rebuilding. Ownership should not be conditional on retaining the vendor for support — the maintenance relationship should continue because it works, not because you have no exit.

A short checklist

Before you publish, confirm the document answers all of these: what problem you are solving; how many pages and documents exist; what happens to old content; the accessibility standard and how it is verified; whether URLs must be preserved; how many people publish and how technical they are; the line items every bidder must price separately; the evaluation criteria and weights; the timeline and any hard constraints; whether questions are permitted; who owns what at the end; and whether maintenance is in or out of scope.

If your solicitation answers those twelve, you will get proposals you can actually compare — which is the entire point of running a procurement rather than just hiring someone.

We read solicitations properly and give a bid or no-bid answer within two business days, including telling you when we are not the right fit. You can send us a solicitation, or read how we approach government web design and municipal website design. More procurement questions are answered on the RFP and procurement FAQ.