WordPress Project Scope: What's Included vs Out-of-Scope (Template Inside)

A WordPress project scope is the written contract between what the agency will build and what the client expects to receive. A good one names every deliverable in plain language, lists what is explicitly out of scope, sets numerical limits on content and revisions, and pins down the unglamorous handover items that nobody remembers until launch week. A bad scope is the document you both pretend to have read, then argue about for three months.

I have shipped over 250 WordPress sites at WitsCode, and the most reliable predictor of whether a project finishes on time is not the team or the budget. It is the scope document. When the scope is specific, projects close cleanly. When it is loose, even small jobs drag for months. This article gives you the scope template I actually use, with the line items most agency proposals quietly skip.

What should be in a WordPress project scope

A complete WordPress project scope answers six questions in writing. What pages are being built and how many of them. What functionality lives on those pages, named by feature. What the client provides versus what the agency produces, including copy, imagery, brand assets, and licenses. What technical baselines the site must meet, such as page speed, accessibility level, and browser support. What the launch handover includes, covering credentials, training, backups, and redirects. And what is explicitly out of scope, written as a list so nobody can claim ambiguity later.

The mistake I see in most agency SOWs is that they enumerate pages and stop. "Homepage, about, services (3), contact, blog template, 404." That is a wireframe, not a scope. It tells you nothing about whether the cookie banner is included, who owns the plugin license keys in year two, or whether a redirect map from the old site is part of the engagement. Those gaps are where projects bleed money.

The forgotten items: a prose tour

The next eight paragraphs cover the line items I see omitted most often. Each one has cost a real client real money on a real project, and each one belongs in your scope as a named deliverable.

The first is the favicon, and specifically the full favicon set. Most agencies ship a single sixteen-by-sixteen ICO file and call it done. A modern site needs an apple-touch-icon for iOS bookmarks, multiple Android icons, a Safari mask-icon, and a web manifest. We had a fintech client whose site ran with the default WordPress favicon for eleven months because nobody had written "favicon" in the scope. Eleven months of every browser tab and Google result silently undermining the brand. A line item costs nothing. A missing favicon costs trust.

The second is the custom 404 page. The default WordPress 404, on most themes, is a wall of nothing. A scoped 404 includes on-brand copy, a search field, links to the top three or four destinations on the site, and an event sent to GA4 so you can monitor broken-link patterns. It takes two hours to build properly. It rescues thousands of visitors a year on any site with traffic, and it is missing from roughly half the agency SOWs I have audited.

The third is the GDPR cookie consent banner, wired to Google Consent Mode v2. This is no longer optional for any site with EU traffic. The banner needs prior consent for analytics and ads cookies, a reject-all option with the same prominence as accept-all, and integration with the analytics stack. I have watched a client receive an ICO complaint because the previous agency installed a "cookie notice" plugin that did not actually block any cookies. The fine was settled, the reputational damage lingered. Name the banner, the consent mode integration, and the cookie audit in the scope.

The fourth is the redirect map, and the most expensive scope omission I have seen in fifteen years was exactly this. On a re-platform from one CMS to WordPress, a four-thousand-page client of ours lost thirty-eight percent of organic traffic in six weeks because the previous agency had not built a redirect map from old URLs to new. It took five months and a six-figure SEO retainer to recover, and the agency lost the account. Every URL on the old site needs a destination on the new site, served as a 301 redirect, and the map needs to be tested against the live old sitemap before launch. The work is mechanical: export the old sitemap, map each URL to its new equivalent in a spreadsheet, dump the result into a redirect plugin or the .htaccess file, then crawl the old sitemap with Screaming Frog after launch and confirm every URL returns a 301 to a 200. It is one of the cheapest deliverables to add and one of the costliest to skip.

The fifth is the robots.txt and staging noindex strategy. The scope should say, in writing, that the staging environment is noindex and password-protected, and that production ships with a robots.txt allowing the site and a submitted XML sitemap. I have lost count of how many staging sites I have found ranking on Google because someone left them open and Google found them anyway. Worse, I have seen production launches that accidentally inherited the staging noindex and stayed invisible to search for weeks. A two-line clause in the scope, plus a launch-day check that the noindex header is gone, prevents both failures.

The sixth is the staging access handover. At launch, who owns the DNS account, the hosting, the WordPress admin, the GitHub repo, the plugin license keys, and the Search Console verification? If the answer is "we will sort it out at the end," you will not. The scope should list every account and assign an owner. The most awkward post-launch email I ever wrote was to a client whose previous agency had registered their domain under the agency's own credit card and disappeared. We had to threaten ICANN dispute proceedings to recover it.

The seventh is the accessibility pass to WCAG 2.2 AA. The scope should name a level, a tooling baseline (axe, Lighthouse, manual keyboard test), and what gets remediated versus flagged. A scoped audit catches contrast failures, missing alt text, keyboard traps, and form-label mismatches before launch, when fixing them is cheap. Bolting accessibility on after a complaint costs three times as much.

The eighth is the image optimisation pipeline: WebP or AVIF conversion at upload, sensible dimensions enforced (no five-thousand-pixel heroes), lazy-loading below the fold, and CDN delivery. Without this in the scope, you end up six months later with a media library full of forty-megabyte PNG files dragging LCP above five seconds. The pipeline is set up once, in two hours, and pays back forever.

The SOW template

Below is the scope addendum I attach to every WordPress engagement at WitsCode. It is opinionated by design. Copy it, adapt the numbers, and challenge yourself to delete nothing.

# WordPress Project Scope Addendum

## In scope (deliverables)

### Build
- [ ] Theme: custom block theme based on [parent], or design-system handover from [Figma file]
- [ ] Page templates: [list each, e.g. home, services, case study, blog index, post, contact, 404, search]
- [ ] Reusable blocks/patterns: [count, e.g. 12 named patterns]
- [ ] Content seed limit: [e.g. 8 pages, 6 posts]; client provides remaining content
- [ ] Forms: [count, e.g. 2 forms, contact + newsletter] with honeypot + Cloudflare Turnstile
- [ ] Search: [native WP / Algolia / Relevanssi], scope of indexed content named

### Forgotten essentials (named, not assumed)
- [ ] Favicon set: ICO, apple-touch-icon, Android icons, mask-icon, manifest
- [ ] Custom 404 page with search, top links, GA4 event
- [ ] GDPR/CCPA cookie consent banner with Google Consent Mode v2
- [ ] Cookie audit + cookie policy page
- [ ] Redirect map from old URLs (CSV provided by [party]); 301s tested pre-launch
- [ ] robots.txt (production); staging noindex + HTTP basic auth
- [ ] XML sitemap submitted to Google Search Console + Bing Webmaster
- [ ] Accessibility pass to WCAG 2.2 AA (axe + manual keyboard, contrast, alt)
- [ ] Image pipeline: WebP/AVIF on upload, max dimensions enforced, lazy-load, CDN
- [ ] Email deliverability: SMTP via [provider], SPF/DKIM/DMARC verified
- [ ] Transactional email templates branded (form notifications, password reset)
- [ ] Backup schedule + one tested restore before launch
- [ ] Security baseline: WAF, custom login URL, 2FA on admins, DISALLOW_FILE_EDIT
- [ ] Page speed targets: LCP < 2.5s, INP < 200ms, CLS < 0.1 on 4G mid-range device

### Analytics and SEO
- [ ] GA4 + Google Tag Manager install with named event taxonomy
- [ ] Search Console + Bing verification, sitemap submission
- [ ] Schema.org: Organization, WebSite, BreadcrumbList minimum
- [ ] Open Graph + Twitter card defaults across templates

### Handover
- [ ] DNS, hosting, WP admin, GitHub repo, GA4, GSC, plugin licenses transferred to client ownership
- [ ] Editor training: 60-minute Loom walkthrough + 30-minute live Q&A
- [ ] Documentation: runbook for common edits, restore procedure, support escalation
- [ ] Browser/device matrix: latest 2 versions of Chrome, Safari, Firefox, Edge; iOS 16+, Android 12+

## Out of scope (explicit)

- Copywriting beyond seed content limit above
- Stock photography license or custom photoshoot
- Translation or multilingual setup (available as add-on)
- Migration of comments, users, or e-commerce orders unless named
- Third-party integrations not listed in build section
- Ongoing SEO retainer, content production, or paid media
- Year-two plugin license renewals (client owns from launch)
- DNS/email hosting beyond the verification step
- Legal review of cookie policy, privacy policy, terms

## Assumptions

- Client provides brand assets (logo SVG, colour tokens, fonts) by [date]
- Client provides redirect map from old URLs by [date]
- Two rounds of revision per template; further rounds billed at [rate]
- Approval cycles do not exceed 5 business days; longer delays shift launch date

## Acceptance criteria

- All in-scope items above ticked off in shared checklist
- Lighthouse scores on home + 2 inner pages: Performance > 90, Accessibility > 95, SEO > 95
- All Tier-1 forms tested end-to-end with notification receipt confirmed
- Restore drill from latest backup completed and signed off

Two pages. Twenty minutes to fill in. Forty hours of fights avoided.

There are three more items I would mention in passing, even though they did not get their own paragraph. Email deliverability is one: a contact form that drops into the spam folder is a contact form that does not exist, so the scope should name an SMTP provider and confirm SPF, DKIM, and DMARC records before launch. Form spam protection is another: a honeypot field plus Cloudflare Turnstile or hCaptcha, named in the scope, prevents the post-launch flood of Russian Cialis enquiries that every unprotected form attracts within a week. And the tested restore drill is the third: not "we installed a backup plugin" but "we restored the site from backup to a sandbox environment on this date and signed it off." Until you have done that, you do not know whether your backups work.

How to use it in a sales conversation

When I send this addendum to a prospect, I do not lead with the checklist. I lead with the question: which of these items do you currently have on your live site? Most clients discover, somewhere between the favicon line and the redirect map line, that their last build skipped six or seven of these. The scope document becomes a diagnostic tool, not a contract appendix.

The other thing it does is force you to be honest about your own delivery. If you cannot tick "tested restore drill" on every project, you do not actually do backups, you install a backup plugin and hope. Writing the scope is how you find out where your process is theatre.

A note on revisions and content seeding

Two clauses earn back their weight every quarter. The first is a revision cap: "two rounds per template, additional rounds billed at the hourly rate." Without it, every project becomes infinite. The second is a content seed limit, named in numbers: "we will populate eight pages and six blog posts from copy you provide; you populate the remainder using the editor training we deliver." Without that line, you end up retyping a hundred-page services catalogue at three in the morning launch week. Neither clause is unfriendly. Both protect the relationship by making expectations legible.

Working with WitsCode

If you are an agency partnering with us on a build, or a brand commissioning a WordPress project directly, we start every engagement by walking the SOW addendum above with you and adapting the numbers to the project. The favicon set, the 404 page, the consent banner, the redirect map, the staging handover, the accessibility pass, the image pipeline, the email deliverability, the backup drill: all of it is in scope by default, because we have been bitten by every one of them on past projects. We do not need to be reminded.

If you would like a copy of this addendum as a Google Doc or a Notion template, or you want us to scope your next WordPress build with this level of specificity, get in touch with WitsCode. We will send the template, talk through the line items that apply to your project, and quote a fixed-scope build with each deliverable named. The unglamorous items are where reputations are made.