Website Redesign Scope What To Include

Don't have time to read this? Schedule a 30-minute call and we will walk you through exactly how this applies to your business. Book a call

Key Takeaways

• Scope is not a formality. It is the document that prevents the most expensive problems a redesign project can encounter.
• Vague scopes produce vague results. Specific scopes produce projects that can be priced accurately, delivered predictably, and evaluated honestly.
• What is explicitly out of scope matters as much as what is in scope.
• Every "we assumed that was included" conversation traces back to a scope document that was not specific enough.

What Scope Actually Does

A scope document does three things.

First, it defines what the project is. Not what it might include or what is aspirationally possible, but what is specifically committed to by both parties.

Second, it protects the client. When a deliverable is in the scope document, the client has something to hold the vendor accountable against. When it is not, any dispute about whether it should have been included defaults in the vendor's favor.

Third, it protects the vendor. A clear scope prevents the project from expanding indefinitely as new requirements are surfaced mid-build, each framed as something that was obviously always part of the original agreement.

A good scope document is not adversarial. It is clear.

What Belongs in Scope

Pages and Templates

Every page and page template must be named explicitly. Not "all the pages we discussed" but a numbered list:

1. Homepage
2. Services overview
3. Service page: Website Redesign (template — applies to 4 service pages)
4. About
5. Team (CMS-driven, template)
6. Case Studies index
7. Case Study (CMS-driven template)
8. Blog index
9. Blog post (CMS-driven template)
10. Contact
11. Privacy Policy
12. 404

If there are additional pages, they are added to this list. If a page is not on the list, it is not in scope.

For template-based pages, specify how many instances the template covers. "Service page template, applies to 4 service pages" is different from "service page template, unlimited pages."

Content Deliverables

Specify what content work is included:

• Content audit: Review of existing pages with keep, rewrite, or cut decisions
• Messaging framework: Core messaging document covering positioning, differentiator, proof points, and primary CTA hierarchy
• Copywriting: List every page for which new copy is being written as part of the project
• Copy migration: List every page where existing copy is being reformatted or migrated, not rewritten
• Content review cycles: How many rounds of copy revisions are included before approval?

Content scope is where most disputes originate. "You said you'd write the copy" versus "we said we'd review your copy" is a conversation that happens when this section is vague.

Design Deliverables

List every design output included in the project:

• Wireframes for each unique page template
• Mobile wireframes for each unique page template (separate line item, not assumed)
• High-fidelity mockups for each unique page template
• Design system: typography, color palette, spacing system, button styles, form elements, component library
• Design review cycles: how many rounds of revisions are included per mockup deliverable?

Be explicit about mobile. Many scopes say "responsive design" without specifying that mobile layouts are designed separately rather than generated automatically from desktop layouts. These produce very different outcomes.

Development Deliverables

• Full site build in the specified platform
• CMS configuration: all content types, fields, and editor permissions as specified in the requirements document
• Third-party integrations: list each one explicitly by name
• Redirect implementation: 301 redirects for every URL in the SEO transition plan
• Performance optimization: images, scripts, and caching configured to meet specified Core Web Vitals targets
• Accessibility: implementation to WCAG 2.1 AA standard

QA Deliverables

• Cross-browser testing: Chrome, Firefox, Safari, Edge (current and one version prior)
• Device testing: desktop breakpoints, tablet (iPad), and mobile (minimum two device types)
• Form and integration testing: every form and integration verified end-to-end
• Performance verification: final Core Web Vitals scores documented before launch
• Redirect verification: every redirect in the SEO plan tested and confirmed

Launch and Post-Launch Deliverables

• Go-live checklist: documented verification of all pre-launch items
• Analytics configuration: GA4 with conversion events tested and firing correctly
• Search Console setup: site and sitemap submitted, indexing confirmed
• SSL verification: certificate active on live domain
• Handoff documentation: written CMS guide for all content types
• Team training: CMS walkthrough (specify format: live, recorded, or written)
• Post-launch support period: number of weeks and what is covered (bug fixes only, or expanded)
• 30/60/90-day review: included or separately scoped?

What Belongs Out of Scope

Explicitly naming what is out of scope prevents "we assumed that was included" from becoming a project-ending conversation.

Common out-of-scope items that should be named:

• Additional pages beyond the list above: Any page not explicitly listed requires a separate scope and pricing discussion.
• Additional integrations: Any integration not listed in the scope document is not included.
• Brand identity work: Logo design, visual identity system, or brand strategy beyond the design system described above.
• Content writing beyond the listed pages: The blog, resource library, product descriptions, or any page not explicitly listed as a copywriting deliverable.
• Ongoing SEO work: Keyword research, link building, or content strategy for post-launch growth.
• Paid advertising or campaign landing pages: Unless specifically listed, paid traffic landing pages are out of scope.
• Training beyond the listed scope: Additional training sessions, video production, or written guides beyond the CMS walkthrough.
• Hosting, domain, or third-party subscription costs: Platform fees, hosting costs, and any subscription required for included integrations.

Webflow Development Services

Webflow Experts On-Demand

Whether you're starting fresh or need a full revamp—we create fast, modern Webflow sites built for growth.

Let's talk

How to Handle Scope Changes

Every redesign project encounters requests for scope additions after work has begun. The scope document is not meant to prevent discussion. It is meant to ensure those discussions are explicit.

A good scope change process:

1. The client identifies a new requirement
2. The vendor documents it as a change request with a scope description and cost estimate
3. Both parties approve the change in writing before work begins on it
4. The timeline is updated to reflect any impact from the addition

Change requests documented in writing, with approval before execution, prevent the end-of-project invoicing surprises that damage client relationships and lead to disputes.

For an understanding of what the formal scope of work document looks like as a legal and contractual instrument, rather than just a planning tool, that resource covers the structure and language used in binding project agreements.

Connecting scope to technical requirements documentation ensures that every functional and performance specification in the requirements document has a corresponding line item in the scope, with no gaps between what was specified and what was committed to.

For a view of how scope is defined and managed inside a structured website redesign engagement, including how change requests are handled and what the approval process looks like, the service page covers the process from discovery through handoff.

At LOW/CODE Agency, every project is scoped with the specificity described in this article. We are a leading AI product team for SMBs and startups. We have shipped 450+ products for companies including Medtronic, American Express, and Coca-Cola.

Our scope documents name every page, every integration, every content deliverable, and every post-launch requirement explicitly. Clients know exactly what they are getting. We know exactly what we are building.

We build in Webflow, which reduces many of the platform-related scope ambiguities that arise on projects using custom development or legacy CMS platforms.

If you want a scope that leaves nothing to interpretation, let's talk.