Page scope
Separate unique page types, reusable templates, content sections, and future work.
SWAP DESIGN / PROJECT SCOPE GUIDE
What should be clear before a UK small-business WordPress project starts?
A plain-English guide to pages, responsibilities, on-page SEO, testing, ownership, handover, and support boundaries.
UK-FIRST / SCOPE
A clear project brief is more useful than a long feature list.
A useful WordPress project scope explains what the website needs to do, which pages and templates are included, who is responsible for content, what functionality is required, how the site will be tested, and what the business receives at handover. Making those decisions visible early keeps the work easier to review and reduces surprises later.
This guide is for UK small-business owners who want to understand the work before development begins. It focuses on decisions that affect delivery: content readiness, page structure, integrations, migration, forms, on-page SEO, testing, access, and ongoing support.
PROJECT DIRECTION
Keep the important decisions visible.
Pages, responsibilities, technical work, and handover should be understood before the build gets too far.
01Pages
02Responsibilities
03Launch checks
WHAT YOU GET
The important parts stay visible from the beginning.
Use the scope to understand the work, the decisions, and the next step before anything becomes unnecessarily complicated.
Content responsibility
Make writing, editing, image preparation, uploading, and approvals visible.
Technical decisions
Record forms, integrations, migration, hosting, analytics, and testing requirements.
Handover clarity
Keep access, ownership, documentation, updates, and support boundaries understandable.
01
Start with the business
The project should describe the decision the website needs to help someone make.
Before the page list, explain the audience, the service, the important questions, and the action the visitor should take. That context helps separate necessary work from features that are merely available.
01
Business and service context
02
Primary audience and visitor questions
03
Important pages and user paths
04
Content, proof, and approval responsibilities
05
Forms, integrations, and account access
02
Make the deliverables visible
A useful scope names the work instead of hiding it under “website development.”
The document should explain pages, templates, design direction, WordPress setup, on-page SEO, forms, integrations, responsive behaviour, testing, launch preparation, and handover. If a task matters to the website, it should be visible in the agreed work.
01
Page and template count
02
Design direction and review points
03
WordPress development and content setup
04
On-page SEO and internal-link foundations
05
Mobile, browser, link, and form checks
06
Access guidance and handover notes
03
Keep support boundaries honest
Launch is a handover point, not a reason to leave every future task undefined.
A project can explain what happens after launch without making unsupported support promises. Separate routine updates, plugin updates, error fixes, new pages, major development, hosting issues, and migrations so the next conversation starts with a shared understanding.
01
What the owner can update
02
What help remains available
03
How new work is identified
04
Which hosting or third-party tasks need separate access
4answer-ready questions
ANSWER-READY CONTENT
Useful answers before you decide what to do next.
The questions below are written for the decision a small-business owner is actually trying to make.
The project should explain the goals, pages, templates, content responsibilities, design process, functionality, integrations, on-page SEO, testing, launch, ownership, revisions, exclusions, and handover.
The project should state who writes, supplies, edits, uploads, and approves the content and images. Clear responsibility helps prevent the build from waiting on assumptions.
The business should understand who controls the domain, hosting, WordPress administration, analytics, files, and licences. The exact access arrangement should be documented before launch.
A practical launch check can cover mobile layouts, browsers, forms, links, headings, canonical output, indexability, accessibility basics, analytics events, backups, and the visible visitor journey.
START WITH A CONVERSATION
Have a website question?
Share the problem in a few lines and I will help you identify the next practical step.