Websites
What should a golf club website project include?
What your golf club website brief should cover, from visitor journeys, content, and bookings to search, supplier handover, and launch, so you commission a useful site.
Start with the job the website needs to do
Start with your club's priorities. You might need more visitor bookings, clearer membership enquiries, or a better route in for society organisers. Agree which journeys matter most before anyone talks about layouts.
Give each journey a clear next step, and decide who at the club will handle the response. A good brief describes what success would look like, without promising a result the website can't deliver on its own.
Make each journey easy to follow
Prospective members, visitors, and society organisers arrive with different questions. Plan the pages around what each of them needs to know: what's available, what the experience includes, and how to enquire or book.
Start with an inventory of the current site and decide what to keep, combine, rewrite, or retire. If a URL changes, put its new destination in the migration plan rather than leaving old links behind.
Treat the words and imagery as part of the build
Ask who will write the copy, supply the photographs, organise filming, and approve the work. These are part of making the site useful, not details to sort out at the end.
Your club's identity should carry through the page designs. Choose imagery that helps someone understand the place and the experience. Put formats and usage rights in the brief, so your team knows where each asset can be used.
Be precise about bookings and enquiries
A link to a booking platform, an embedded form, and a direct integration with another system are different pieces of work. Ask which one is included and what the visitor will actually experience.
For enquiries, agree who receives them, what information is collected, what confirmation the visitor sees, and who follows up. If a CRM or a website assistant is part of the plan, check exactly what it covers and which connections it supports.
Include search and migration in the scope
Talk about page titles, helpful headings, useful answers, and links between related pages. Important information should be readable as text on the page, with photographs and video supporting the explanation.
Decide whether the project keeps every visible URL or changes some of them. A move that only changes hosting needs a tested copy of the site, a controlled DNS change, and monitoring of both the old and the new hosting. A move that changes URLs also needs a map from current to new URLs, permanent redirects, updated internal links and canonicals, and a new sitemap. Nobody should promise you rankings or a place in AI answers.
Put ownership and recovery in writing
Changing supplier takes more than a folder of files. For everything that moves, name who hands it over, who takes it on, what evidence changes hands, how it will be checked, and who to call if the transfer fails.
The eight areas below cover the domain, content, customer routes, access, support, and launch. Swap the role descriptions for named people before anyone signs off.
Test the full journey before launch
Review the site on desktop and mobile. Follow the important routes, send test enquiries, check where they arrive, and see what happens when a form fails.
Check existing links, redirects, video controls, and keyboard access. Make one person responsible for the launch decision and the early monitoring. A finished design is only part of the handover. The website also has to work for the people visiting it and for the team receiving their interest.
Changing supplier: who hands over what
If your club is moving from one supplier to another, nothing is really handed over until the person taking it on has checked and accepted it. Agree each of these eight areas with the outgoing supplier, the new supplier, and your own team.
A move that only changes hosting and one that changes URLs are different jobs. Google’s guidance for a hosting change with the same visible URLs focuses on testing the new hosting, changing DNS, monitoring both hosts, and delaying shutdown. Its separate guidance for a move with URL changes adds URL mapping, permanent redirects, updated canonicals and internal links, a new sitemap, and monitoring.
Domain, DNS and hosting control
- Outgoing
- Names the account holder who can grant or transfer access to the registrar, DNS, and current hosting.
- Incoming
- Runs the new hosting and any agreed DNS change.
- What changes hands
- Verified account access, a current DNS record export, hosting details, and support contacts.
- Accepted when
- The club can get into the registrar, the new owner can reach the agreed hosting, and the DNS records needed are recorded and checked.
- If it goes wrong
- Keep the current host and its support until the move is accepted. Know who can reverse or correct a DNS change.
URLs, content and redirects
- Outgoing
- Lists every current page, file, and media URL, plus any existing redirects.
- Incoming
- Owns the content decisions, URL map, and redirects for every changed address.
- What changes hands
- A map of old to new URLs showing what stays, moves, combines, or retires, with a named redirect owner.
- Accepted when
- Each changed old address reaches its new page, then canonicals, internal links, and the sitemap are checked. If visible URLs don't change, skip the URL map and follow the hosting-only plan.
- If it goes wrong
- Keep the original list, and a named person to fix redirects, missing content, or unexpected errors.
Copy, photography and film
- Outgoing
- Identifies the source files, where they live, who made them, and any known usage conditions.
- Incoming
- Confirms who stores, publishes, and approves each asset afterwards.
- What changes hands
- A list of assets with editable originals where supplied, published versions, credits, usage rights, and any expiry or territory limits.
- Accepted when
- The copy and assets you need open in the agreed formats, match the list, and have an approval or rights record.
- If it goes wrong
- Know who can replace a missing or disputed asset, and where the approved previous version is kept.
Booking and action routes
- Outgoing
- Lists every booking link, embedded form, export, and supported connection, saying exactly which type each one is.
- Incoming
- Names who sets up and checks each visitor route on the new site.
- What changes hands
- Destination URLs, the scope of each embed or connection, the access needed, and where the visitor should end up.
- Accepted when
- Each route works on desktop and mobile and takes the visitor to the agreed external page, form, or connection.
- If it goes wrong
- A named supplier or club contact who can restore the previous link or provide the agreed fallback.
Enquiries and follow-up
- Outgoing
- Documents where each form or enquiry route sends its information now, and the confirmation visitors see.
- Incoming
- Names the club team or person who receives and owns each type of enquiry.
- What changes hands
- The fields, destination, confirmation copy, access needed, and who follows up.
- Accepted when
- Agreed test details pass validation, show the confirmation, and reach the named owner before launch.
- If it goes wrong
- An escalation contact, and an approved alternative way in if an enquiry route fails or is delayed.
Analytics, consent and search access
- Outgoing
- Identifies the current analytics, consent, and search properties, who owns them, and any handover restrictions.
- Incoming
- Names who keeps or receives the access needed for measurement and search checks.
- What changes hands
- Property IDs, a record of access roles, the consent setup, the verification method, and handover status. Never passwords.
- Accepted when
- The named owners can reach the agreed properties, verification is still in place, and the live consent state matches what was approved.
- If it goes wrong
- A named account administrator and the platform's support route for lost access or broken verification.
Editing, training and support
- Outgoing
- Explains current editing access, maintenance duties, and anything that still needs supplier help.
- Incoming
- Names the people who will edit, approve, and support the site afterwards.
- What changes hands
- Access by role, training material, a support contact, the response arrangement, and the agreed scope of ongoing care.
- Accepted when
- Each named person can do the agreed editing task, and knows how to ask for support without using someone else's account.
- If it goes wrong
- Know who administers access, the urgent support route, and the approved way to restore content or permissions.
Launch acceptance and monitoring
- Outgoing
- Stays available for the agreed transfer checks, and for anything only the current supplier can provide.
- Incoming
- Names who makes the launch decision and who owns the early technical, content, and customer route checks.
- What changes hands
- A launch checklist: priority journeys, mobile, keyboard access, links, redirects where needed, canonicals, sitemap, intended robots.txt rules, temporary crawl or noindex blocks, forms, and who is monitoring.
- Accepted when
- For either kind of move, robots.txt is as intended, temporary crawl blocks and HTML or HTTP noindex rules are gone, and live URLs return the expected responses after the switch. The decision maker records a pass, an accepted exception, or a blocker for every check.
- If it goes wrong
- A go/no-go contact, a way to correct problems, and the conditions for going back to the previous hosting or visitor route if an important check fails.
Still deciding how much needs to change?
Read our guide to deciding whether to improve, redesign, or rebuild your golf club website before you agree the supplier handover.
Your next website
Start with what your club needs.
Capture Sites brings website strategy, design, and managed delivery together. We agree the content, journeys, supported connections, and ongoing care around your club.
