How to choose a web design agency: a UK buyer guide

A web design agency should help you turn business requirements into a website that customers can understand, use and trust. UK buyers need to compare more than visual style. Define the customer journeys, content, technical work, integrations, ownership and launch evidence before comparing fees, then test the finished site against those agreed requirements.

Choosing a web design agency can feel straightforward until the proposals arrive. One supplier prices a set of page designs, another includes research and copy, and a third talks about a complete digital platform. The totals may look comparable while the work, responsibilities and handover are not.

That ambiguity creates expensive decisions later. Content is missing when design starts, useful search pages disappear during a rebuild, and a polished form sends incomplete enquiries to the wrong place.

This guide gives UK business owners and marketing teams a practical way to define the job, inspect the evidence and commission a website they can operate. It focuses on buyer decisions rather than promising a particular ranking or sales result. Sources and GRO's published service details were checked on 21 October 2026.

Define the website decision before contacting an agency

A website project needs a business decision at its centre. A request to modernise the site describes a feeling, not a deliverable. It gives an agency room to propose attractive screens without establishing what a customer must understand, which actions matter or what the business needs to receive after those actions.

Begin with the event that prompted the project. Sales may be answering the same suitability question on every call. Marketing may be sending paid traffic to a general page that covers several services. Staff may be unable to update an important condition without a developer. Each problem suggests a different scope. Only some require a complete rebuild.

Write the problem as an observable account. Name the page or journey, the intended visitor, what they try to do and where the current experience becomes unclear. Avoid diagnosing the cause in the same sentence. A buyer who abandons a form may be confused by the offer, blocked by an error or simply not ready. The agency still needs to investigate.

Set one primary commercial purpose

Choose the main job the website must do for the business. It might help prospects compare technical services, request an assessment, book an appointment or configure a product before speaking to sales. A site can support several actions, but one purpose should guide the difficult choices about structure, content and budget.

The purpose must connect to a customer task. Generate more leads is too broad because it does not describe the people, the action or the quality threshold. Help facilities managers request a site assessment for an eligible building is clearer. It indicates who the journey serves, what information needs explaining and what the form must collect.

Record the actions that do not represent success. A download may be useful without being a sales opportunity. A phone-number tap does not prove that a call connected. A form submission may be unsuitable. Keeping these distinctions visible stops a supplier from treating every interaction as an equivalent conversion.

Decide whether to improve or replace

List what already works before discussing a new platform. Useful service pages, familiar navigation, accessible components, search visibility and functioning CRM connections are assets. A redesign should preserve or deliberately replace them. Starting from a blank canvas can feel creative while making the project responsible for rebuilding value that already exists.

A focused improvement may be enough when one campaign or customer route causes the problem. GRO's landing page design service is an example of a narrower engagement: one audience, one offer and one useful action. A full build is more defensible when structure, content, editing limits and technical dependencies obstruct several journeys together.

Ask each prospective agency how it will reach that decision. A credible answer should include inspection of the current site and conversations with people who receive enquiries. Be cautious if the recommendation appears fixed before discovery, particularly when every problem leads to the same platform or package.

Name the decision owner

Website projects collect opinions quickly. Sales, marketing, operations and senior leaders may all see different problems because they use the site differently. Their input is useful, but an undefined approval group can create contradictory feedback and repeated redesign. Name one person who can resolve those conflicts against the agreed customer purpose.

The owner does not need to make every specialist judgement. They coordinate evidence, assign factual questions and confirm when a requirement has been met. Give subject experts specific review tasks. Sales can check enquiry context; operations can verify delivery descriptions; the website owner can confirm access and technical dependencies.

Define which decisions the agency can make without another meeting. Visual spacing may fall within an approved direction, while changing an eligibility rule cannot. This boundary keeps work moving without allowing design convenience to rewrite the offer.

Finish the first brief with a decision statement. For example: commission the smallest website project that helps the named audience understand suitability, complete the agreed action and pass usable context to the responsible team. That sentence gives later choices a test. If a proposed feature does not support it, the feature needs a separate reason.

Translate stakeholder requests into customer requirements

Stakeholders often propose solutions before describing the problem. Sales asks for live chat, finance asks for gated pricing and a director asks for a larger homepage video. Record each request, then ask which customer or operating difficulty it addresses. The answer may support the idea, suggest a simpler option or show that the request belongs outside the current project.

Give competing requirements an explicit trade-off. Live chat might help a staffed team respond during working hours, but it also creates an expectation when nobody is available. Gated pricing might qualify interest, yet it can stop an early buyer from deciding whether the service is plausible. The project owner needs the evidence and the operational consequence, not a vote based on preference.

Describe requirements without prescribing an interface where possible. A requirement to help visitors distinguish emergency and planned work leaves room for content, navigation or form design. A requirement to add two red buttons may lock the team into an answer before the customer task is understood. Agencies should be able to explain the solution they choose.

Keep non-functional requirements alongside page features. Editing access, accessibility, performance, privacy, security and recovery shape the whole system. They are easy to omit when a brief consists only of screens. Assign an acceptance method and owner to each so they survive into testing.

Audit the current website and customer journey

A buyer needs a reliable account of the current site before asking an agency to replace it. Without one, the proposal may be based on a homepage tour and a list of desired features. Important entry pages, redirects, third-party tools and internal processes surface only after the schedule and fee have been agreed.

Build an inventory of public pages, forms, booking routes, downloads and integrations. Include the page address, purpose, owner, current action and any known dependency. Use analytics and search data as supporting evidence, not as the inventory itself. A low-traffic legal page can still be required, and a high-traffic article may not be part of a buying journey.

Follow real entry points

Customers do not all begin at the homepage. They arrive through search results, adverts, referrals, saved links and emails. Identify the pages that introduce important services or receive campaign traffic. Open each one without assuming the visitor has read anything else, then ask whether the page explains the offer, evidence and next step in context.

Trace several complete routes. A prospective customer might move from a guide to a service page, then to a form and confirmation. Record every page, interaction and handover. The audit should include error states, not only the ideal route. Submit an incomplete form, use an invalid email address and check what happens when an appointment is unavailable.

Ask customer-facing colleagues where the journey continues outside the website. Does an enquiry create a CRM record, send an email or enter a shared inbox? Who responds, and what information do they need? A website can appear complete while leaving the operational handover dependent on somebody copying details between systems.

Separate observation from interpretation

Record what happened before deciding why. An analytics report can show that many visits ended on a page, but it cannot by itself show disappointment. A sales colleague can report recurring confusion, but one memorable call does not establish how often it occurs. Keep the account, the measured pattern and the proposed explanation in separate fields.

Use page recordings, surveys or usability sessions only with an appropriate privacy and research approach. The aim is to understand a customer task, not to collect as much behavioural data as possible. Ask the agency which question each method will answer and how the result will change a design decision.

Accessibility checks also belong in the audit. Try the main journeys with a keyboard, inspect visible focus, increase text size and review forms for clear labels and errors. The W3C accessibility principles provide a useful framework for perceivable, operable, understandable and compatible content. An automated scan can identify some problems, but it does not replace task-based review.

Protect useful assets

Mark pages and functions that must survive the project. Include accurate content, approved customer evidence, working calculators, useful downloads and search destinations. A new visual direction does not make those assets obsolete. The redesign needs an explicit plan for retaining, improving or retiring each one.

Record current page addresses separately. If a valuable page moves, the agency needs an old-to-new mapping and a suitable redirect. If it disappears, the business should understand what user need and search destination are being removed. This work becomes much harder after the old site has been overwritten.

Export or document information that is difficult to recreate. Form definitions, analytics events, consent categories, domain settings and integration credentials may sit across several accounts. Do not pass passwords around in a spreadsheet. Confirm account ownership, authorised users and a secure transfer route.

Turn findings into priorities

Group findings by impact on the named customer task. A broken enquiry submission needs attention before a decorative inconsistency. A confusing service boundary may matter more than an old photograph. Assign each issue an owner and a decision, such as retain, repair, rewrite, replace or investigate.

Avoid turning the audit into a list of every imperfection. A long list can make a complete rebuild appear inevitable even when most items share one cause. Look for repeated patterns: the same form on several pages, a common page template or a navigation label used across the site. One component change may solve many observations.

The audit should end with a short account of what the project must improve, what it must preserve and what remains unknown. Send that account to shortlisted agencies. Their response will reveal whether they engage with the specific business problem or return a standard package description.

Check the content management reality

Ask current editors to perform ordinary tasks while somebody observes. Publishing a case study, changing a service condition and replacing a team member can reveal workarounds that a technical inventory misses. Record the steps, permissions and points where the editor needs outside help.

Distinguish a platform limitation from a training or governance problem. A team may avoid updates because roles are unclear, not because the system cannot make them. Replacing the platform will not settle who approves a price or checks a claim. Carry those responsibilities into the proposed operating model.

Review content that lives outside normal pages. Reusable banners, navigation, pop-ups, transactional emails and structured data may be controlled in different places. Include them in the audit when they affect customer understanding or search presentation. Otherwise they can retain old language after the main pages change.

Check export options before accepting claims that migration will be easy. Some systems export text but not relationships, images or form history. The agency should inspect a representative export and state what needs transformation, manual work or deliberate retirement.

Turn business requirements into a comparable scope

Comparable proposals begin with a comparable request. Page counts alone do not create one. Ten pages can mean ten unique templates and research assignments, or one template populated with supplied copy. A buyer needs to state the expected work around each page, the shared components and the responsibilities on both sides.

Create a page map with a purpose for every destination. Record the audience, main question, content owner, primary action and next destination. This exposes pages that duplicate one another and pages that have no defined job. It also gives the agency enough context to propose a sensible structure rather than simply copying the existing menu.

Describe deliverables in inspectable terms

Replace broad labels with things you can review. Website design might include a customer journey map, page structure, visual system, responsive layouts and component states. Development might include the agreed templates, content management setup, form implementation, redirects and browser checks. Content might include interviews, page plans, drafts and a revision allowance.

Specify the state of delivery. A design file is not a working website. A working preview is not a production launch. A form that displays correctly is not complete until its submission, destination, confirmation and failure handling have been checked. Each milestone needs an output and an acceptance question.

Use the same discipline for smaller words around the interface. Navigation labels, buttons, form instructions, validation messages and confirmation emails influence the customer journey. Assign responsibility for them. Otherwise they are written quickly during development, when nobody is expecting a content decision.

Define functionality through scenarios

A feature list can conceal different interpretations. CRM integration might mean sending a basic contact record, or it might include deduplication, ownership, source fields and workflow enrolment. Describe a scenario: when a visitor submits the consultation form, create or update the contact, preserve the consent choice, assign the correct team and show an accurate confirmation.

Add exceptions. What happens when required information is missing, the connection fails or a duplicate contact exists? The project need not solve every unusual condition, but the proposal should identify the agreed behaviour and any manual fallback. This prevents a happy-path demonstration from being mistaken for a dependable process.

For complex products, separate the page from the specialist tool. A calculator, quotation tool or product configurator can require its own logic, data and testing. GRO treats calculators and quote tools as a distinct service because the buying interaction needs more than a styled form. Ask whether specialist functionality is included, integrated or explicitly excluded.

State content responsibilities

Content delays many website projects because everyone assumes somebody else will supply it. For every page, identify whether the business provides approved copy, the agency edits existing material or a writer conducts research and creates new drafts. Record who supplies evidence, photographs, credentials and legal wording.

Do not use lorem ipsum as the basis for approving representative pages. Real headings, conditions and form questions reveal whether a layout supports the information. A short placeholder can make any design look balanced, then collapse when a necessary explanation or qualification arrives.

GRO's website copywriting buyer guide explains how to prepare evidence and review page roles. Even when writing is outside the web design contract, the design schedule must recognise when approved content will be available and what happens if it changes after layout approval.

Record exclusions and assumptions

Ask each supplier to state what is not included. Common boundaries concern photography, copywriting, data migration, ecommerce records, specialist accessibility testing, external licences, hosting, ongoing maintenance and post-launch changes. An exclusion is not automatically a problem. A hidden exclusion is.

List assumptions that affect effort. The proposal may assume a certain number of unique templates, one language, clean product data or access to an existing CRM feature. Ask what changes if the assumption is wrong. This makes contingency visible before it becomes an urgent change request.

Finish with a responsibility matrix. For each deliverable, show who supplies information, who produces the work, who reviews it and who accepts it. The matrix does not need management jargon. Its purpose is to stop an essential task from sitting between organisations without an owner.

Use acceptance criteria that allow judgement

Acceptance criteria should be specific without pretending design is mechanical. A service page can be accepted when it states suitability, presents approved evidence, links to the relevant next step and works in the agreed layouts. That criterion leaves room for good design while protecting the information a buyer needs.

Avoid criteria such as looks professional or feels premium unless the brief defines what those words mean for this brand and audience. Use examples and principles: restrained typography, clear hierarchy, approved colour use and photography showing the real service. Reviewers can then explain a concern against the chosen direction.

For functionality, include inputs, outcome and evidence. A successful consultation submission should create the expected record, preserve agreed fields, notify the right owner and display the approved confirmation. The test result can be retained without exposing customer data.

Agree who can waive a criterion and how the waiver is recorded. Sometimes launch proceeds with a minor known issue. The record should name the impact, owner and planned treatment. Silent exceptions are more dangerous because nobody knows whether they were accepted or missed.

Build the site structure around buyer tasks

Information architecture is the arrangement and labelling of content so people can find a useful route. It should begin with customer tasks and service differences, not the company's internal departments. A visitor does not need to understand your reporting lines before they can identify the right service.

Ask the agency to show how the proposed structure follows the audit. Every main navigation label should lead to a recognisable category or action. Every service page should have a distinct purpose. Supporting guides should add depth without repeating the same sales page under a different title.

Give each page one clear job

Write a job statement for each proposed page. The homepage can orient an unfamiliar visitor and provide routes to the main offers. A service page can help a relevant buyer judge suitability. A case study can show how a defined piece of work was approached and what supported evidence is available.

A page may answer several questions while serving one decision. That focus helps resolve content disputes. If a long company history does not help the visitor judge the service, it can move to the about page. If an eligibility condition determines whether somebody can enquire, it belongs close to the service explanation rather than in a generic footer.

Avoid producing near-identical pages solely for keywords, locations or audience labels. Ask what actually changes for that visitor. Different regulations, fulfilment routes or service conditions may justify separate pages. A different phrase with the same offer and evidence may not.

Design useful routes between pages

Internal links should answer the question created by the surrounding content. A guide can direct a ready reader to the relevant service. A service page can offer a detailed comparison or case study. A confirmation page can explain the next step without forcing the visitor back to the homepage.

Check routes in both directions. Breadcrumbs, related content and clear navigation help somebody regain context after arriving on an internal page. Do not rely on a user following the sequence imagined in a workshop. Each important destination needs enough orientation to work as an entry point.

The Google SEO Starter Guide recommends logical site organisation and crawlable links, but structure should not become an exercise in pleasing a crawler. Clear labels and useful relationships help people first. Search systems benefit from many of the same signals because the site's meaning is less ambiguous.

Prototype before polishing

Review simple page structures before committing to detailed visual work. A wireframe can show heading order, evidence, forms and onward routes without asking reviewers to debate colours. Use realistic content so the team can judge whether the sequence supports the customer task.

Prototype important interactions as well as pages. A multi-step form, calculator or booking route needs states for progress, errors, confirmation and return visits. Ask what information is saved, when consent is requested and how somebody can correct an answer. Static screenshots rarely answer those questions.

Use a representative page to test the system. Choose one with normal complexity: service explanation, proof, a qualification and an enquiry route. Agree how that page works before extending the pattern. This reduces the risk of applying an unsuitable component across the whole site and discovering the problem during final content entry.

Keep navigation within human language

Internal programme names and marketing frameworks can be meaningful to the business while confusing visitors. Test labels with people who know the problem but not the organisation. Ask what they expect to find under each one. A correct guess matters more than a clever phrase.

Make the primary action specific. Talk to us can cover several outcomes. Request a site assessment or book a strategy call tells the visitor more about the commitment. The page must then explain what follows, who responds and what information is useful.

The agreed structure should be documented outside the design file. Keep page addresses, titles, purposes and owners in an editable register. It becomes the basis for content production, redirect planning, analytics checks and future maintenance.

Model content before choosing fields

Content modelling identifies the repeated information the business needs to manage. A case study may have a sector, challenge, approach, evidence, service links and permission status. Defining those parts helps editors maintain consistency and helps designers create components that reflect meaning rather than arbitrary text lengths.

Do not split content into fields solely to control visual alignment. An editor should understand what belongs in each field and why. A component with eyebrow, kicker, label and micro-title fields can produce tidy screens while encouraging vague repetition. Use the fewest fields that preserve meaning and reuse.

Decide which relationships need structure. Connecting a case study to relevant services can support useful navigation and easier maintenance. Hard-coding the same links into several page bodies makes later changes slower and more error prone. The agency should show how relationships appear to editors and visitors.

Plan for missing values. Not every project will have an approved statistic or quotation. The design should remain coherent without fabricated filler. Optional evidence must disappear cleanly rather than leaving empty frames or pressuring staff to publish an unsupported claim.

Plan content, evidence and enquiry paths together

Design cannot compensate for missing business information. A convincing website needs accurate service explanations, usable proof and a next step that matches how the team sells. These elements should develop together. Treating copy as material to pour into finished boxes makes late factual changes more likely.

Build an evidence pack before drafting. Gather current service descriptions, recurring sales questions, delivery constraints, approved credentials and customer evidence the business has permission to publish. Date each source and name an owner who can confirm it. Old brochures can be useful clues, but they are not automatically current authority.

Turn claims into checkable statements

For every proposed claim, ask what it means and what supports it. Fast response might refer to an internal target, an observed average or a general aspiration. Those are different statements. If the evidence does not establish a public promise, write a precise process explanation instead.

Keep the limits with the evidence. A certification may belong to one individual, a result may concern one project and a guarantee may have conditions. Removing those boundaries because they complicate a design makes the page misleading. The layout has to accommodate accurate explanation.

Separate proof that something happened from permission to publish it. A project record may substantiate a result without authorising use of the customer's name or data. The content register should contain both approvals. When either is missing, choose another supported example or omit the claim.

Match calls to action with the real response

The button and form should describe the next event honestly. If a submission requests a conversation, do not label it Get a quote unless the business actually supplies a quotation from that information. If a booking requires confirmation, explain that before the visitor assumes the time is fixed.

Ask only for information used at that stage. A sales team may want a complete specification, while a first-time visitor can provide only a goal and contact details. Determine which answers change routing or preparation. Defer questions that no one uses until later.

Visible labels, instructions and understandable error messages support more people than placeholder text alone. The W3C form labelling tutorial explains why controls need clear associations. Include keyboard use, error recovery and confirmation in acceptance testing, not as optional polish.

Connect the enquiry to sales follow-up

Map each form field to its destination. Confirm the field name, type, required status and CRM property where applicable. Decide how records are assigned and how the responsible person knows a new enquiry has arrived. Capture available page or campaign context without claiming that attribution will always be complete.

Write the confirmation from the customer's perspective. State what was received and what happens next, without inventing a response deadline. Provide a safe route for urgent or different enquiries where the business has one. Test the message in the page and in any email the visitor receives.

Create a failure path. If the integration is unavailable, the website should not silently discard a submission or claim success. Agree logging, notifications and a manual recovery process proportionate to the enquiry. Test that process with the people who will use it.

Treat content maintenance as part of design

Ask how staff will update prices, service conditions, team details and evidence. A flexible content management system can still be difficult if editors face unlabeled fields or fear breaking layouts. The agency should demonstrate representative edits and explain which components have safeguards.

Assign owners and review dates to changing information. The website cannot know when an accreditation expires or a service boundary changes. A simple register can prompt the right person to check those details. Maintenance is an organisational responsibility supported by the system, not a feature that makes every page permanently current.

Plan retirement as well as publication. When a service ends, decide whether its page needs an explanation, a replacement route or removal. Do not redirect every retired page to the homepage. The response should help visitors who followed an old link understand what happened.

Create a content production sequence

Write high-risk pages early. Pages involving regulated claims, several stakeholders or complex functionality can change the structure. Leaving them until the end may reveal that approved components cannot hold the necessary explanation. Easier pages can then follow the settled pattern.

Separate factual approval from language refinement. First confirm the offer, exclusions, evidence and next step. Then improve clarity and voice. Mixing both reviews encourages a polished sentence to survive even when its underlying claim remains unresolved.

Use one source of truth for each page. A collaborative document or content system can work, provided the team can identify the current version and approval state. Avoid copying drafts into several presentation files. Differences become difficult to reconcile when launch approaches.

Plan image production against approved content. Photography and illustration should support actual services and evidence. A designer who receives final messages late may choose generic imagery simply to complete layouts. Give visual work the customer task and factual boundaries before commissioning it.

Assess design quality, accessibility and mobile behaviour

Visual quality matters because hierarchy, spacing and imagery help people understand a page. It should be assessed through the customer task rather than taste alone. Ask how the design directs attention, distinguishes choices, presents evidence and keeps the main action recognisable without making everything compete.

Review a complete system, not one polished desktop screen. Typography, colour, buttons, forms, tables, navigation and content cards need consistent states. Include hover, focus, error, disabled and loading states where relevant. A component that looks finished in one screenshot may fail when text wraps or data is missing.

Test representative content at small sizes

Open the designs at the narrowest agreed layout and use realistic headings, labels and tables. Check that text remains readable, controls stay reachable and the order still makes sense. A mobile design is more than a desktop layout stacked vertically. Priority and interaction often need reconsideration.

Use real devices where the project scope allows, along with browser viewport checks. Device testing reveals keyboard, touch and browser behaviour that a design canvas cannot. Record the agreed device and browser support so the supplier and buyer understand what was checked.

Inspect images and diagrams for small-screen legibility. Text inside an image does not reflow, and a wide comparison may become unreadable. Keep essential explanations in the page's HTML. Use alternative text to describe the image's purpose rather than repeating a decorative filename.

Build accessibility into components

Accessibility is easier to maintain when it is part of the component system. Colour contrast, focus indication, heading structure, keyboard order and form feedback should be designed before templates multiply. Fixing the same fault in every instance after launch costs more and can leave inconsistent results.

WCAG 2.2 is an established technical reference, but legal obligations vary by organisation and context. UK public sector websites have specific accessibility regulations and statement requirements. Private organisations should obtain suitable legal guidance for their duties rather than relying on an agency's general assurance.

Ask which checks are automated, which are manual and which involve people using assistive technology. Automated tools find only certain detectable patterns. A passing score cannot prove that a journey is understandable or operable. Request issue evidence, priorities and retest results rather than a badge without scope.

Review motion and interruption

Animation can clarify a state change or relationship. It can also delay reading, move focus or make content uncomfortable. Ask what each motion communicates. Provide controls where repeated or non-essential motion would otherwise continue, and respect reduced-motion preferences in the implementation.

Check overlays, cookie controls, chat widgets and promotional panels together. Each may be acceptable alone while their combined effect blocks a small screen. Test the first visit, returning visit and error states. A customer should not have to close several layers before understanding the offer.

Do not use urgency patterns or hidden defaults to push a decision the page cannot support. Clear conditions and reversible choices build a more dependable journey. Design quality includes what the interface declines to do.

Make design review evidence based

Collect feedback against the agreed page job. Replace I do not like this with the specific concern: the eligibility condition is hard to find, the action label suggests a purchase or the evidence looks detached from the claim. That gives the designer a problem to solve while preserving room for professional judgement.

Limit the number of consolidated review rounds and name the person who resolves conflicts. Share feedback in one system with page and component references. Comments spread across email, chat and meetings make it difficult to establish which instruction is current.

At approval, record the version and the known content assumptions. A design can be approved with a named gap, but the gap must have an owner and consequence. This prevents a temporary placeholder from becoming the production fact by accident.

Build an accessible review sample

Ask for a preview that includes the hardest normal content: a long service name, a validation error, a table, an image with meaningful alternative text and a keyboard-operated menu. A sample built only from short ideal content will not test the component system.

Review zoom and text resizing as separate behaviours. A layout can rearrange correctly at a narrow viewport yet lose content when text is enlarged. Controls should not overlap, truncate required labels or force a two-dimensional scroll for ordinary reading.

Check focus order against the visual order. Responsive layouts sometimes move cards or sidebars while the keyboard sequence follows a different source order. That difference can make the page confusing even when every element technically receives focus.

Retain findings with screenshots, steps and affected components. An issue report that says accessibility problem gives a developer little to reproduce. A precise report supports repair and retesting across every instance of the component.

Protect search visibility during a redesign

A redesign can change page addresses, content, headings, internal links and technical delivery at the same time. Search visibility is not guaranteed before or after the move, but the project can preserve useful destinations and make changes traceable. Ask for a migration plan before development is nearly complete.

Start with the current URL inventory and search evidence. Identify pages receiving relevant visits or links, pages supporting conversions and pages required for customer support. Read the bodies before deciding that two similar titles are duplicates. Their audiences or purposes may differ.

Give every old address a decision

Map each indexable old URL to one of four outcomes: retain unchanged, move to a close replacement, consolidate into a stronger relevant page or return a deliberate removal response. Avoid redirecting unrelated addresses to the homepage. The destination should satisfy the reason somebody followed the old link.

Google's site move guidance recommends preparing URL mappings, using permanent server-side redirects where appropriate and monitoring the move. Keep that mapping as a delivery record. It supports both launch checks and later investigation of unexpected traffic changes.

Preserve page meaning during consolidation. Combining two weak pages does not automatically create one useful page. The replacement needs the relevant information and a coherent customer task. Record which content and links were carried forward so reviewers can check the actual result.

Keep technical signals consistent

Specify canonical addresses, indexability, sitemap inclusion and internal links for the new site. Preview environments should not become competing public copies. Production pages should identify their own intended canonical URL unless there is a documented reason otherwise.

Check structured data against the visible page. A service schema cannot substitute for missing service information, and review markup must not imply ratings the organisation is not entitled to present. Ask the agency what markup it adds, which page content supports it and how it will be maintained.

Retain meaningful titles and descriptions where they still fit the content, then improve them deliberately. A redesign should not replace every useful search snippet with the same brand phrase. Titles need to distinguish pages for people scanning results as well as search systems.

Do not launch several major changes blindly

If possible, separate unrelated infrastructure, domain and content changes. Sometimes the business must combine them, but the risk and monitoring need to reflect that. Changing the domain, platform, navigation and service proposition at once makes cause difficult to identify if performance moves.

Keep the old site available in a controlled archive or export. Do not leave it publicly indexable. The archive gives the team evidence of former content, metadata and routes when a question arises after launch.

Agree a monitoring window without promising recovery by a fixed date. Search systems need time to crawl and process changes, and commercial demand can move for other reasons. Check indexing, crawl errors, important rankings and organic landing pages against the release record. Describe what is known rather than assigning every change to the redesign.

Make SEO responsibility explicit

Some web design proposals include basic technical setup; others include research, content and ongoing search work. Ask for named deliverables rather than an SEO included label. A sitemap, metadata fields and crawlable navigation are useful foundations, but they are not a continuing content or authority programme.

Ask who will complete keyword mapping, page titles, redirects and Search Console checks. Confirm whether the agency or the business supplies final copy. If another specialist is responsible, add the handover points to the plan.

Reject guaranteed ranking promises. Search performance depends on competitors, demand, content usefulness and systems outside the agency's control. A credible supplier can describe its work, checks and evidence without promising a position it cannot control.

Review international and campaign variants

If the business serves several countries or languages, decide whether pages differ by language, offer, legal terms or fulfilment. A flag selector alone does not create a useful international structure. Translation ownership, locale addresses and alternate-page signals need an agreed plan.

Campaign parameters and tracking templates should survive redirects where appropriate without creating uncontrolled duplicate pages. Ask how the site handles query strings, filtered content and printable versions. The canonical and indexing approach should match the actual function.

Temporary campaign pages need retirement rules. Record the owner, end condition and replacement route. Leaving expired offers indexable can mislead visitors, while deleting them without considering inbound links can create unnecessary dead ends.

Check that staging and test environments remain out of ordinary search results. Access controls and noindex settings can both play a role, but the production launch must not inherit a blocking directive. Include this reversal in the launch checklist.

Specify performance, security, privacy and integrations

Technical requirements need acceptance criteria linked to real pages and journeys. Fast, secure and GDPR compliant are goals, not complete specifications. Ask the agency to describe its implementation, testing scope, dependencies and maintenance responsibility.

Performance starts with what the visitor needs. Identify representative pages and interactions, then agree how they will be tested. GRO's website speed optimisation guide explains the difference between controlled tests and field data. Use both appropriately, without treating one score as proof of every experience.

Define a performance budget and test route

A performance budget can set limits for page weight, script use or key timings in the agreed environment. The exact measures should fit the project and be documented. If the site depends on video, chat, maps or a product tool, include those dependencies rather than testing an empty template.

Check loading, interaction and layout stability on the pages that matter. Repeat tests under comparable conditions and retain the underlying measurements. A faster homepage does not resolve a hesitant calculator or a booking embed that moves the page.

Third-party scripts deserve an owner. Analytics, advertising tags and widgets can affect performance, privacy and reliability. List each one, its purpose and who can approve its removal. New tags should follow the same process after launch.

Set security responsibilities

Require encrypted transport, supported software, controlled administrative access, backups and a recovery plan appropriate to the platform. Ask who applies updates and monitors failures. A managed service can reduce the buyer's work, but it does not remove the need to know who is accountable.

Use individual accounts and multi-factor authentication where the platform supports it. Avoid a shared admin login passed between staff and suppliers. Record who can change the domain, hosting, website and connected tools, then remove access when somebody no longer needs it.

The National Cyber Security Centre guide for small organisations covers account protection, backups and preparation. Ask the supplier how those principles apply to the specific delivery. A generic statement that the platform is secure does not explain configuration, updates or incident response.

Treat consent and data handling as functional work

Inventory cookies, pixels and similar technologies before choosing a consent tool. The configuration must reflect what the site actually loads. The ICO's storage and access technology guidance was finalised in April 2026 and explains how PECR and data protection rules apply. Obtain specialist advice where needed.

Test the site before and after consent choices. Non-essential technology should follow the configured legal basis and consent behaviour. A banner that says the right words while tags load regardless is not a completed implementation.

Forms need appropriate privacy information close to the collection point. Decide what information is necessary, where it goes, who can see it and how long it is kept. The design agency can implement approved wording and controls, but the business remains responsible for knowing why it processes the information.

Verify integrations end to end

List systems, account editions, licences and owners. A feature available in a demonstration may not exist in the buyer's subscription. Confirm access early and identify any fee outside the agency proposal.

Create test records that staff can recognise and remove. Follow each one from the website to the destination, assignment, notification and response step. Check duplicate behaviour and required fields. Screenshots of a successful API request do not prove that the sales user received a workable record.

Document manual fallbacks for important failures. If booking is unavailable, provide an accurate alternative. If a CRM connection stops, the team needs a way to detect and recover submissions. A resilient journey makes failure visible and gives somebody responsibility for action.

Plan data migration as a separate workstream

Moving articles, products, users or customer records is different from creating page layouts. Establish the source fields, destination model, transformation rules and validation sample. Count records before and after where that is meaningful, while respecting privacy and retention decisions.

Clean data before migration when the business can define the rules. Duplicate service categories or inconsistent dates can become harder to fix after they drive new templates. Do not allow a supplier to invent corrections to unclear business data. Give unresolved cases an owner.

Use a sample migration early. It should include normal records and difficult examples such as missing images, long titles or legacy formatting. Review the rendered result and the underlying fields. A count match alone can conceal broken relationships or inaccessible documents.

Decide what will not move. Obsolete drafts, expired personal data and unsupported file types may need secure disposal or a controlled archive. Record the decision and authority. Migration is not a reason to preserve every item indefinitely.

Compare proposals, costs and commercial terms

Price comparison only becomes useful after scope comparison. A lower quote may exclude discovery, content, migration or testing. A higher quote may include work the business does not need. Convert every proposal into the same set of deliverables, assumptions, exclusions and continuing costs before judging value.

Create a comparison table with evidence, not a single score. Include problem understanding, proposed scope, content responsibility, technical delivery, migration, testing, handover, support and commercial terms. Record questions beside gaps rather than assuming the answer that makes a favourite supplier look stronger.

Compare the full commitment

Add external costs such as hosting, plugins, fonts, stock assets, payment services and specialist tools. Separate one-off implementation from recurring subscriptions and ongoing support. State whether prices include VAT and what changes after any introductory period.

Include internal effort. Interviews, evidence gathering, content approval, data cleaning and testing take staff time. A cheaper proposal that transfers most work to an already busy team may cost more in practice or create delay. Estimate the roles and decisions required rather than inventing a generic hourly value.

GRO currently publishes a confirmed full website price of £6,000, or £500 a month for 12 months, with the same total, on its website design and development service. That price was checked on 21 October 2026. The proposal confirms page scope, VAT treatment, hosting and ongoing services; specialist functionality, migration and external licences need explicit treatment. Use the same scope discipline when comparing any supplier.

Ask for reasons, not only features

A proposal should connect its method to the buyer's evidence. If it recommends a new content system, ask which current constraint it resolves. If it proposes many templates, ask which customer tasks require them. The explanation matters because the business will make future changes after the initial project.

Portfolio work can show visual and technical capability, but inspect the live sites where possible. Ask what the agency delivered and what the client supplied. A strong photograph or established brand can make a page look impressive without revealing the quality of research, content modelling or integration work.

Case studies need boundaries. Look for the starting problem, actual scope, evidence and period. A result may be genuine without proving that the same outcome will occur for your business. Ask the supplier to explain how the example informs its approach, not to treat it as a forecast.

Examine change control

Find out how changes are priced and approved. A useful process distinguishes correction of agreed work from a new requirement. It records the effect on fee and schedule before production continues. Vague unlimited revisions can create as much uncertainty as an inflexible one-round limit.

Agree what happens when the business supplies content late or changes the offer. The contract should explain dependencies without giving either party permission to leave the project indefinitely unresolved. Named decision dates and consequences make planning easier, but no supplier should promise a launch date without the required inputs.

Ask how disputes about acceptance are handled. Each deliverable should point back to the agreed requirements and review evidence. Subjective design still involves judgement, but customer tasks, approved direction and documented states give the conversation a firmer basis.

Read the commercial terms carefully

Check payment stages, cancellation, liability, warranties and support boundaries with appropriate professional advice. Understand what happens to work in progress if the project stops. Confirm whether deposits are refundable and what acceptance triggers the next payment.

Look for third-party conditions. A font, plugin, stock image or hosted service may remain subject to its own licence even when the site files transfer. Ask for a dependency register with owner, renewal date and exit option.

Avoid deciding under artificial urgency. A web project affects customer access, data and operations. A supplier can state genuine availability without pressuring the buyer to skip due diligence. Take enough time to compare like with like and resolve material gaps.

Use a weighted proposal review carefully

A scorecard can make differences visible if the weights reflect the project. Give more weight to the customer journey, content and integration when those are the reason for the work. A generic procurement template may overvalue presentation polish and undervalue migration or handover.

Set scoring definitions before opening proposals. A high score for evidence might require direct reference to the audit, a relevant example and a testable method. Without definitions, reviewers use the numbers to express preference and the table creates an appearance of rigour without consistency.

Review large scoring differences in conversation. One person may have found a material exclusion that others missed. Resolve the factual point before averaging scores. Keep written concerns beside the result so the final decision can be explained later.

Do not let the total hide a non-negotiable gap. A supplier that cannot meet a required data, accessibility or ownership condition should not win because it scored highly on several optional features. Mark pass conditions separately from weighted preferences.

Work through a hypothetical cost comparison

Consider two hypothetical proposals for the same eight-page site. Supplier A quotes £4,800 but excludes copy, migration and three months of support. Supplier B quotes £7,200 including those items. The £2,400 difference is not yet a saving because the buyer has not priced the excluded work or confirmed that it can provide it internally.

List each excluded deliverable and obtain a like-for-like amount or a realistic internal resource plan. Suppose copy and migration are worth £2,000 in comparable purchased work, with support still unpriced. Supplier A is now at £6,800 before support. The example does not establish a market rate. It shows why scope changes the arithmetic.

Add recurring costs separately. If one proposal uses £900 a year of licences and another uses £300, the difference over three years is £1,800, assuming prices do not change. Keep the assumption visible and ask who owns each subscription. Do not combine a recurring estimate with a fixed fee without showing the period.

Finally, compare risk and internal capacity. If the business lacks somebody to manage the excluded migration, an apparently cheaper route may not be deliverable. If the buyer already has approved copy and a technical team, paying for duplicate work may add little. The correct comparison follows the actual organisation.

Set ownership, access and handover before work starts

Ownership questions are easiest to resolve in the contract and hardest after a relationship ends. The buyer needs practical control of the domain, hosting, content system, analytics and connected accounts, along with clarity about intellectual property and third-party licences. Obtain legal advice for the actual agreement.

Create an account register during discovery. Record the service, business owner, administrative users, recovery method and billing owner. Do not put passwords in the register. Use the platform's invitation and role controls so access can be changed without sharing a master credential.

Distinguish ownership from access

A supplier can give the business an editor login while retaining control of hosting or the domain. That may be an intentional managed arrangement, but it needs to be explicit. Ask who can move the site, change DNS, export content, install updates and recover an account.

Confirm the format of deliverables. Design source files, code, exported content, image originals and documentation are separate items. A production website may depend on a proprietary builder or hosted feature that cannot be transferred in the same form.

Ask what happens if the agency stops trading or the buyer changes provider. A practical exit plan identifies the files, exports, credentials and notice required. It should not depend on one person's memory.

Plan the editing model

Identify the changes staff will make routinely. These may include services, team profiles, articles, case studies and form options. Ask the agency to demonstrate them on the preview using the proposed roles. The business needs enough control to keep information accurate without exposing every technical setting.

Use structured fields where consistency matters, but leave room for meaningful variation. A rigid template can force every service into the same explanation. An unrestricted page builder can let layouts and accessibility drift. The right balance follows the content model and the skills of the editing team.

Document publishing checks. An editor should know how to preview, add alternative text, choose headings, check links and confirm the mobile layout. Training should use the actual system and representative content, not a generic product tour.

Specify the handover pack

Require a current page and redirect list, component guide, account register, dependency register, integration map, analytics event list, test record and known-issues log. Include instructions for backups, restoration and routine updates. The list can be proportionate to the project, but it should cover the systems needed to operate the site.

Record configuration decisions and reasons. Future staff need to know why a form asks a question, why a script loads or why an old address redirects. Without that context, a well-intentioned tidy-up can remove something important.

Ask the agency to walk through a normal update and one failure. For example, publish a service change, then explain how the team would respond if form notifications stopped. Handover becomes more useful when it tests real responsibilities.

Agree ongoing support boundaries

Separate warranty corrections, maintenance and new development. A warranty may cover delivered work that does not meet the agreed requirement. Maintenance may cover updates, monitoring and backups. New functionality belongs to a change request. Ask for examples so the categories are understandable.

Set contact routes and severity definitions without inventing a universal response promise. A broken payment or enquiry route is different from a minor spacing issue. The support agreement should describe how the supplier classifies and communicates each type.

Review continuing access. Remove temporary users, reduce privileges and confirm billing ownership after launch. Schedule a later account review. Good handover narrows dependence while keeping agreed support available.

Test the exit before accepting the operating model

Ask the supplier to describe how a future provider would receive the site. The answer should cover files, data exports, domain control, licences and reasonable documentation. A managed platform may impose limits, but those limits must be visible before purchase.

Check whether forms, analytics history and customer data can be exported in usable formats. Not every dataset should transfer, particularly where retention limits apply. The business needs a deliberate decision rather than discovering that information is trapped or copied without a lawful purpose.

Confirm the process for ending paid services. Some dependencies may stop immediately; others need a transition. Record notice periods, renewal dates and the person authorised to cancel. Automatic renewals should not depend on an old employee's card or inbox.

An exit test is not a sign of mistrust. It checks that the operating model is understandable. A supplier confident in its work should be able to explain how control and continuity are preserved if the commercial relationship changes.

Test the launch and the first 90 days

Launch is a controlled change, not the moment testing begins. The release decision should compare the finished preview with the agreed journeys, content and technical requirements. Keep evidence of the exact version reviewed so last-minute changes cannot bypass acceptance.

Build a launch checklist around customer tasks. Open important entry pages, follow navigation, submit forms, recover from errors and inspect confirmations. Check on agreed browsers and devices. Verify that content, page titles, links, consent behaviour and analytics match the approved version.

Test content and function together

Read every key page in its rendered layout. Confirm headings, qualifications, proof, buttons and form instructions. Check that images support the surrounding explanation and that alternative text is useful. A technically successful build can still publish an outdated price or a button with the wrong promise.

Test links and redirects from an external list. Do not rely solely on clicking the new navigation. Old bookmarks and search results reach addresses the new menu may never expose. Confirm that each redirect reaches a relevant final page without an unnecessary chain.

Submit enquiries using realistic but clearly marked test details. Verify the website state, notification, CRM record, assignment and any automation. Remove the records afterwards in line with the test plan. Ask the receiving team to confirm that the information is sufficient for its next action.

Prepare release and recovery

Record the production owner, timing, domain changes and people available to verify the result. Keep a known good version and a deliberate recovery method. A rollback can affect new enquiries or content created after launch, so it should be planned rather than treated as a simple undo button.

Lower domain timing values in advance only when the infrastructure plan requires it and the responsible specialist approves. Confirm certificates, redirects and email-related records separately. A website launch should not casually overwrite services that share the domain.

Communicate what changes and where staff should report problems. Give customer-facing teams the new routes and expected confirmation. They may spot an enquiry or message problem before analytics does.

Verify production immediately

Open the live site independently of the preview. Check representative pages, assets, forms, consent, canonical addresses, indexability and the sitemap. Confirm the deployed revision matches the approved version. Review server or platform status for errors.

Monitor enquiries and integrations rather than assuming a successful test covers every live condition. Check that legitimate submissions arrive and that spam controls do not block the intended audience. Avoid using real personal data for unnecessary diagnostics.

Review search tooling for crawl and indexing problems after systems have had time to observe the release. Keep the launch record beside those reports. A change in visibility may reflect migration, content, seasonality or competition, so investigate before asserting a cause.

Use the first 90 days to learn

Set review questions before launch. Can visitors find the relevant service? Do forms produce enough context for follow-up? Which pages receive appropriate traffic? Are editors able to keep information current? Questions guide measurement more usefully than a dashboard of every available number.

Combine quantitative and operational evidence. Analytics can show completed actions and page routes subject to consent and implementation. Sales can report suitability and progression. Support can identify repeated confusion. None alone establishes the complete commercial effect.

Prioritise observed problems over a backlog of speculative enhancements. Fix inaccurate information, broken paths and integration failures first. Then consider changes that answer a defined question. Do not start continuous experimentation merely because the tooling exists.

End the 90-day review with decisions. Retain what works, repair documented friction and assign owners to changing content. Record unresolved questions and the evidence required. The website becomes an operated business system rather than a project that slowly drifts after launch.

Triage problems without losing the evidence

Create three launch categories: customer-blocking failures, material content or integration defects, and lower-impact improvements. A form that loses enquiries belongs in the first group. An outdated qualification that could mislead a buyer needs prompt correction. A preference about card spacing can wait.

For a serious issue, preserve the page, time, steps and affected record before changing several things. A clear incident account helps the team reproduce the cause and confirm the repair. Avoid sharing personal submission details more widely than required.

When a fix reaches production, repeat the original task and check nearby journeys that use the same component. A repair to one form may affect every form built from its template. Close the issue only when the observed failure is resolved in the live environment.

Keep improvement ideas separate from defects. Launch attention can produce many suggestions because staff are looking closely at the site. Capturing them is useful, but mixing them into urgent repair work increases change risk and makes the tested revision difficult to identify.

Establish a calm publishing rhythm

After the initial review, agree how ordinary website changes move from request to publication. A simple route can include an owner, factual check, preview and production verification. The level of review should reflect the consequence. Correcting a spelling mistake is different from changing a service condition or adding a new tracking technology.

Bundle related low-risk improvements where that makes testing easier. Frequent isolated changes can consume attention and leave little record of what affected a page. Keep urgent customer or security repairs separate, with their own evidence and approval.

Measure maintenance through useful signals. Broken links, failed submissions, outdated claims and unsupported software matter more than the number of tickets closed. Review a sample of important journeys regularly and after a dependency changes.

Give the website owner authority to decline additions that lack a purpose or owner. Every new widget, page and form creates future work. A small, well-maintained system often serves customers better than a growing collection of features nobody is responsible for checking.

Questions UK buyers ask about web design agencies

How do I choose a good web design agency in the UK?

Choose an agency that can connect its proposal to your customers, content, systems and operating responsibilities. Give shortlisted suppliers the same problem statement and ask for inspectable deliverables, assumptions, exclusions and evidence. Compare who will research the journey, write or load content, migrate URLs, implement forms, test the site and support it after launch.

Inspect live work where possible, then ask what the agency actually delivered. Check commercial terms, ownership, third-party licences and access with appropriate advisers. A strong visual portfolio helps, but the better buying evidence is a clear method, relevant questions and a proposal that explains why the scope fits your business.

How much does a business website cost in the UK?

There is no dependable universal price because page types, content, integrations, migrations and testing differ. Compare written proposals for the same requirements and add internal time, recurring software, hosting and support. Separate a design file from a complete working and launched website.

GRO publishes a full website price of £6,000, or £500 a month for 12 months, with the same total, checked on 21 October 2026. Its proposal confirms scope, VAT, hosting and ongoing services. Other suppliers will price differently. Treat any public figure as context, then obtain a current quote tied to your pages, functionality and responsibilities.

How long does a website design project take?

The useful answer depends on scope and readiness. A focused landing page, a brochure website and a complex integrated platform have different research, content and testing needs. Ask the supplier to show dependencies and milestones rather than promising a date before it has seen the content, accounts and decision process.

Buyer delays often come from missing evidence, unresolved feedback or unavailable access. Prepare page owners, approved facts and a named decision-maker before production. The proposal should explain what each party supplies and what happens when an assumption changes. That creates a plan you can manage without pretending every issue can be predicted on day one.

Should I use a freelancer or a web design agency?

Choose the delivery model that covers the actual work and risk. A capable freelancer may be an excellent fit for a focused site with clear content and few integrations. An agency may offer several disciplines and more cover, but the buyer still needs to know who performs the work and how decisions are coordinated.

Compare named people, availability, specialist gaps, quality control and continuity. A large team is not automatically better, and one person is not automatically cheaper once external help is added. Require the same clarity on scope, testing, ownership and handover from either model. The contract should reflect the entity you are actually engaging.

Will a new website automatically improve leads or Google rankings?

No supplier can responsibly guarantee that a redesign will increase leads or secure a ranking. A new site can improve clarity, remove technical problems and support better enquiry handling. Commercial results still depend on demand, traffic quality, the offer, competition and sales follow-up. Search visibility also depends on content usefulness and factors outside the design.

Set separate acceptance and outcome questions. First ask whether the delivered site meets the agreed journeys, content and technical checks. Then observe relevant visits, completed actions and suitable enquiries over an appropriate period. Keep campaign and offer changes in the record so a later movement is not automatically credited to the website.

Take a defined website problem into the next conversation

A good web design purchase begins with a customer task and ends with an operable system. Keep the decision practical:

• Name the audience, journey and business response before comparing designs.
• Preserve useful pages, content and integrations through a documented audit.
• Compare complete deliverables, assumptions, recurring costs and internal work.
• Test accessibility, forms, search migration and account ownership before launch.
• Use production evidence and sales feedback to decide what changes next.

Bring one real page and the question it fails to answer. GRO's website design and development service can help you decide whether a focused improvement or a full build fits that problem. If you want to discuss the route, book a 30 minute strategy call and include the page, intended customer and action your team needs to receive.