A website project rarely follows its original plan without a single adjustment. A new integration becomes necessary, a stakeholder asks for another page, or a form needs to collect different information. The problem is not that change happens. The problem is allowing a request to enter production without defining what it changes, who approves it and how it will be tested.
This website change request checklist Malta businesses can use provides a practical way to control scope after a project has started. It complements the initial website development brief and development contract. It does not replace legal advice or the commercial terms agreed with your supplier.
What counts as a website change request?
A change request is any proposed adjustment that sits outside the approved baseline, or alters an item that has already been accepted. It can affect a page, feature, integration, design, data flow, deadline or acceptance criterion.
- Adding a new landing page, language or customer journey
- Changing an approved page layout or navigation structure
- Connecting a CRM, payment service, booking tool or marketing platform
- Changing forms, tracking, cookies or personal data collection
- Renaming, removing or moving a live URL
- Introducing a new user role, workflow or approval step
- Moving a deadline, launch sequence or handover requirement
A correction that brings work back to the agreed specification is usually a defect, not a scope change. The distinction should be based on the signed brief, proposal, contract and acceptance criteria, not on memory.
1. Record the request before work starts
Put every material request in one shared system, such as a project board or numbered change log. Messages in email or chat can provide context, but the approved record should be easy to find later.
- Unique request number and date
- Requester and business owner
- Plain-language description of the requested change
- Business reason and intended user outcome
- Pages, functions, audiences and systems affected
- Desired deadline and reason for the timing
- Links to supporting copy, designs, rules or examples
Avoid requests such as “make the form smarter” or “add a member area”. Describe what users must be able to do, what the business needs to receive and what will count as complete.
2. Compare the request with the approved baseline
Before estimating anything, identify the original requirement that would change. Reference the relevant section of the brief, sitemap, design, content inventory, integration specification or contract. This makes it possible to separate a genuine addition from a correction to work that was already included.
If the project does not have a stable baseline, pause and establish one. The website discovery workshop guide explains how to define objectives, users, content, risks and deliverables before design and development continue.
3. Define acceptance criteria
Acceptance criteria turn an idea into a testable outcome. Write them from the user and business perspective, then add technical conditions where they matter.
Example: Instead of “add a newsletter form”, specify where the form appears, which fields are required, what validation and confirmation users see, which audience receives the contact, how consent is recorded, which analytics event fires and what happens when the integration is unavailable.
Keep criteria specific enough for a reviewer to make a clear pass or fail decision. Link them to the project’s broader website testing checklist.
4. Assess the full impact
A small visual request can affect more than one workstream. The supplier should assess the request across the following areas before anyone approves it.
Design, content and user journeys
- New layouts, components, copy, images or translations
- Changes to navigation, calls to action or task completion
- Mobile, tablet and desktop behaviour
- Content ownership and approval dependencies
Development and integrations
- Front-end and back-end work
- CMS fields, permissions and editorial workflow
- Third-party APIs, licences and recurring services
- Error handling, data synchronisation and support responsibilities
Use the website integration checklist when a request introduces or changes a connection to another system.
SEO and URLs
If the request changes or removes a public URL, include redirect mapping, internal-link updates, canonical signals, sitemap changes and post-launch checks. Google recommends permanent server-side redirects where a URL has permanently moved and advises directing an old URL to the most relevant new destination. See the official Google Search Central redirect guidance.
Accessibility
New components and interactions should be checked against the same accessibility standard as the rest of the project. Consider keyboard operation, focus order, labels, error messages, contrast, zoom, screen-reader output and reduced-motion preferences. The W3C overview of WCAG is the authoritative starting point, while DCP’s accessibility checklist provides a practical project review.
Privacy, security and analytics
A change to forms, tracking, account areas or integrations can alter what personal data is collected, why it is collected, where it goes and how long it is retained. Recheck privacy notices, consent behaviour, processor arrangements, access controls and deletion procedures. The European Commission explains that a data protection impact assessment may be required where planned processing is likely to create a high risk. Its GDPR obligations guidance is a useful official reference.
Also confirm whether analytics events, conversion definitions, cookie categories or reporting dashboards need to change. Do not let measurement become an afterthought.
5. Estimate the change separately
Ask for a written impact statement before approval. It should show the effect on effort, cost, delivery sequence, dependencies and risk. Avoid hiding the change inside the original project total, because that makes later reconciliation difficult.
- Work included and explicitly excluded
- Assumptions used for the estimate
- People or suppliers required
- Third-party fees or licences, if applicable
- Effect on milestones and launch date
- Testing and review time
- Warranty, support or maintenance implications
No universal price or duration applies. A request may be quick to build but slow to approve because it depends on copy, legal review, an external vendor or access to another system. Compare the estimate with the dependency guidance in the website development timeline article.
6. Make one recorded decision
Give each request one of four outcomes: approve, reject, defer or split. Record the decision, approver, date and any conditions. If it is approved, update the budget, delivery plan and acceptance criteria before implementation begins.
For larger requests, splitting the work is often safer. Deliver the smallest complete outcome first, then place optional enhancements into a later phase. A verbal “go ahead” without an updated record invites disputes about scope, cost and completion.
7. Build and test in a controlled environment
Do not experiment directly on the live site. Implement the approved change in a development or staging environment where practical, use version control or documented configuration changes, and take an appropriate backup before release.
- Prepare test cases from the acceptance criteria.
- Test the changed function and the surrounding journey.
- Check mobile layouts and major browsers relevant to the audience.
- Retest accessibility, privacy, analytics, SEO and security impacts.
- Ask the named business owner to review evidence and accept the change.
- Schedule release, monitoring and a rollback route.
For higher-risk changes, use the backup and recovery checklist and website security checklist as release gates.
8. Close the request properly
A change is not complete when the code is deployed. Update the sitemap, content inventory, integration register, credentials record, privacy documentation, analytics specification, training notes and handover pack where relevant. Record the release date, test evidence, approver and any follow-up work.
This prevents the website documentation from drifting away from the live system and makes future maintenance easier.
Copyable website change request checklist
- Request has a unique ID, owner and business reason
- Affected pages, users, systems and data are identified
- Original baseline and changed requirement are referenced
- Acceptance criteria are specific and testable
- Design, content, development and integration impacts are assessed
- SEO, accessibility, privacy, security and analytics are reviewed
- Cost, timing, dependencies and exclusions are documented
- Decision and authorised approver are recorded
- Testing, release, monitoring and rollback are planned
- Documentation and handover records are updated after release
Keep change useful, visible and controlled
Change control should not make a website project rigid. It should help the business make informed trade-offs while protecting delivery quality. A short, consistent record is usually enough for a small request. A feature that changes user journeys, data processing, integrations or live URLs deserves a fuller assessment.
If your Malta business needs help defining, building or managing a website project, explore DCP’s web design and development service.
Featured image: Photo by Hal Gatewood on Unsplash.
