Last updated: November 3, 2026
The gap between a WordPress quote and the final invoice is almost never dishonesty — it is discovered scope: the 400 extra pages, the CRM nobody mentioned, the “small” calculator embedded in a page since 2019. Scoping is the work of discovering those before they are change orders.
What belongs in a WordPress project scope?
- Content inventory — a crawl-based count of pages, posts, and files, flagged keep / improve / retire. Counts, not impressions: when we migrated Lando & Anastasi to WordPress, the inventory was 576+ pages — a number that shapes budget honestly before anyone designs anything.
- Template list — the distinct page designs the build actually requires. Twelve templates and forty templates are different projects.
- Content model — the structured types beyond pages/posts (team, case studies, products, locations) and the fields editors need.
- Integration list — every system the site touches: CRM, marketing automation, analytics, search, gated content, embeds. Named, with an owner for credentials on each.
- Migration plan — what moves, how (scripted vs. manual), and who does editorial cleanup.
- Environments & workflow — local/staging/production, version control, and how changes deploy.
- Performance, accessibility & SEO targets — Core Web Vitals expectations, WCAG level, full redirect map ownership.
- QA & launch plan — device/browser coverage, form testing against real destinations, analytics verification, rollback plan.
Which scope items blow up budgets most often?
Integrations and migration volume, in that order. An integration list that says “HubSpot” when reality is HubSpot forms + lifecycle tracking + a legacy Salesforce sync is a five-figure surprise waiting for a status call. Migration surprises are quieter but relentless — every uncounted page is cost somebody eats later. Third place: the unowned redirect map, which is how sites lose SEO in an otherwise good rebuild.
What should you prepare before asking for quotes?
You don’t need a specification — you need honest inputs: a site crawl (or ask each vendor to run one and cite counts), your integration list with owners, examples of sites whose function you want (not just looks), your team’s editing reality, and a real budget range. Vendors scope to the information they get; vague inputs produce padded-or-lowballed guesses, and you cannot tell which is which.
How do you compare quotes once they arrive?
Normalize them against your scope document: does each quote cite the same page counts, template counts, and integrations? Does it name what is excluded? Does it separate build cost from post-launch support? A materially lower number usually means an assumption difference — find it before you sign, not after. The vendor-vetting questions in our guide to choosing a web partner pair well with this exercise; pricing clarity under scrutiny is one of the strongest signals a partner sends. For where budgets typically land and why, see our custom WordPress cost guide.
What are the red flags in a scope document?
Read scopes for what they refuse to commit to. Warning signs: no page or template counts anywhere (“full site redesign” is a sentence, not a scope); “content migration included” with no volume attached; integrations listed as product names without pattern or ownership; QA described as “thorough testing” with no device or browser matrix; no redirect plan; and hosting or post-launch support waved at rather than priced. Any one of these is where the extra invoice lives. The same instincts apply to the relationship itself — the vendor warning signs in Red Flags in a Web Vendor Relationship usually show up first in the paperwork.
How should change orders work?
A change order is not a failure — discovered scope is normal. What separates healthy projects is process: the change is written down with its cost and schedule impact before the work happens, you approve or defer it explicitly, and a running scope ledger keeps the current total visible. The failure mode is the drip — small unpriced accommodations that surface as one large number at the end. If a vendor’s answer to “how do changes get priced?” is “we’ll work it out,” you have found the future dispute.
A WordPress scoping checklist you can copy
Paste this into the brief you send vendors. Every line is a countable or a named owner; if you cannot fill one in yet, say so, and the discovery phase will.
- Inventory: total pages, posts and files from a crawl; the keep / improve / retire split; how many pages need rewriting versus moving as-is.
- Templates and content model: the distinct page designs you expect; the structured content types (team, case studies, products, locations) and the fields each needs.
- Integrations: every system the site touches, with what flows which way and who owns credentials. HubSpot forms alone and HubSpot forms plus lifecycle tracking plus a Salesforce sync are different line items.
- Migration: what moves, scripted or by hand, who cleans up editorially, and the deadline it has to meet.
- Environments and workflow: local, staging and production; version control; how a change gets from a request to a deploy.
- Targets: Core Web Vitals thresholds, the WCAG level you need (public-serving organizations usually need AA), and who owns the redirect map.
- Launch: the device and browser matrix, form tests against real destinations, analytics verification, and the rollback plan.
- After launch: hosting, support hours, response times, and who maintains plugins and core updates.
How long does scoping take, and who should be in the room?
For a typical B2B marketing site, one to three weeks. The crawl and inventory take a day; the integration conversations take the rest, because the people who know what the CRM actually does are rarely the people who asked for the quote. Get marketing, whoever administers the CRM and analytics, IT if it touches hosting or single sign-on, and one editor who lives in the CMS daily. The editor is the one most teams forget and the one whose answers change the template count most.
Scale changes the shape, not the steps. When Sisense moved 3,600 pages, the inventory was the project; when Anika consolidated four sites into one, the scope was mostly deciding what not to carry over (350 pages became about 75, and 46 plugins became 15). Either way the counts came first, and the design came second.
Should you pay for discovery before the build?
Usually, yes, and especially when integrations or migration volume are uncertain. A paid discovery phase produces the scope document above, with counts the vendor has verified rather than assumed, and it is cheap compared with the change orders it prevents. The healthy version has a fixed price, a fixed deliverable you can take to any vendor, and credit against the build if you proceed. The unhealthy version is a sales call with a longer name. Ask what the deliverable is and whether you own it.
Frequently asked questions
What is the difference between a scope and a statement of work?
The scope is the inventory of what the site must contain and do. The statement of work adds who does each part, the schedule, the price, and how changes are handled. A good statement of work cites the scope line by line; a weak one restates the sales proposal.
How detailed does the content inventory need to be?
Detailed enough that two vendors would count the same number. A spreadsheet from a crawl with one row per URL, a keep / improve / retire decision, and a note on the template each page uses is the standard. It is also the first draft of your redirect map.
Can a scope be too detailed?
Yes, when it specifies solutions instead of needs. “A three-column card grid with hover states” ties the vendor’s hands and dates quickly; “a way for editors to feature three case studies on any page without a developer” tells them what to design for. Count what you can count, and describe outcomes for the rest.
What does a well-scoped project feel like?
Boring, in the best way: discovery confirms the inventory instead of exploding it, integrations are proven on staging early, content migrates on schedule because someone counted, and launch week is a checklist rather than a scramble. That is the experience our WordPress development team scopes for — and it starts before the quote, not after the contract.
