What to send a developer before a website redesign
Guide. Published 14 October 2026.
Before a developer can quote a redesign, they need to see what you have and to know what you want. Gather the access, the content decisions, a note of what must keep working, your key web addresses and your goals, and the quote can be written from facts instead of guesses. Send what you have and say what is missing.
In short
- Give the developer access to the live site, shared securely and never in plain email.
- Decide which pages stay, which go, and who supplies the text and images.
- Say what must keep working, and list the web addresses that matter most.
- Write down your goals, what bothers you, and who approves the result.
A redesign is quoted task by task, and every unknown becomes a question, an assumption or a guess. On our projects the biggest delay is usually waiting for feedback or content, so having your material ready keeps things moving.
Access: what to send and how to send it
A developer cannot sensibly quote for a site they cannot look at. Where they exist, gather these:
- Hosting access. A cPanel login is ideal. It lets the developer see the site files, database and plugins, and take a backup before changing anything.
- WordPress admin login, if the site runs on WordPress. Where you can, create a separate administrator account for the developer instead of sharing your own.
- Domain registrar and DNS. Who registered the domain, and who controls its DNS, the settings that point the name at your hosting and email. DNS only needs to change at go-live if the site moves to new hosting, so at the start it is usually enough to say who manages it.
- Google Search Console and Google Analytics, if you have them. Adding the developer as a user is safer than sharing your Google password.
If you do not know where the site is hosted or who holds the domain, say so. It is common when a previous designer set things up, and better found out early.
Share access details securely, never in plain email. Ask your developer how they prefer to receive logins. A password manager's sharing feature is one common route. When the project ends, remove the developer's account or change the password.
Content, functionality and web addresses
A content inventory
Go through the live site page by page and list the address of each page and what should happen to it. A spreadsheet is fine.
| What | What to note |
|---|---|
| Pages to keep | The address of each, and whether the text stays as it is or needs updating. |
| Pages to drop | Old services, expired offers and duplicates. If other sites link to a page you drop, say so, so its old address can point to the closest remaining page instead of an error. |
| New pages | Anything the new site needs that the old one lacks. |
| Text you will supply | Which pages, and who writes them. If you do not have any text yet, tell your developer early. |
| Images | Photos you own or may use, at the largest size you have. |
| Logo files | See brand assets below. |
What must keep working
List every function your visitors or your staff rely on, such as:
- contact or quote forms, and who receives the messages;
- bookings or appointment requests;
- online payments or a shop;
- member areas and logins;
- integrations, such as a mailing list sign-up, a calendar or a link to another system.
For each one, write what a visitor does and what happens next. Systems that already work are usually worth keeping, and writing them down stops them being lost in a rebuild. Whether a feature is a job for an existing plugin or for custom code changes the quote; our guide on WordPress plugin or custom code explains the difference.
Your existing web addresses
Send the addresses (URLs) of the pages that matter most: the home page, your main service or product pages, and anything other sites link to. Note where an address is shared or printed, such as an email signature or a directory listing. Search Console, if you have it, can show which pages get clicks from Google searches.
If the new site uses different addresses, each old address should be mapped to the page that replaces it, so that visitors and search engines land on the right new page and not on an error. The list you send is what makes that mapping possible. No one can promise a search ranking, and we do not.
Brand, goals and who decides
Brand assets
- A vector logo, usually an SVG, AI, EPS or vector PDF file, so it stays sharp at any size. A PNG or JPG is a fallback. See logo file formats.
- Colours. The exact values if you have them, or the file they come from.
- Fonts. The names, and the font files if you have them. Say whether you must keep them or are open to change.
- Brand guidelines, if a designer ever made a document.
If you have none of these, say so. It changes the work.
Your goals, and what bothers you
Write a few sentences on what the site should achieve, such as more enquiries, online sales or easier updating, and what bothers you about it now. Be specific: "few visitors find the contact page" tells a developer more than "make it modern". Say whether you mainly want a fresh look, new functionality, or both.
Sites you like
Send two or three links, with a line on what you like about each, such as the layout, the colours or how easy things are to find. One you dislike is useful too. They show your taste and are not instructions to copy.
Who writes, and who approves
Name one person who sends content and gives feedback, and anyone else who must sign off. On our projects you review a draft on a private copy and approve it before anything goes live, so know who gives that approval.
A checklist to copy and send
Copy this into an email or a document, fill in what you can, and mark what is missing.
Access
- Website address, and the name of the hosting company
- Hosting or cPanel login, shared securely
- WordPress admin login, ideally a separate account for the developer
- Where the domain is registered, and who manages its DNS
- Search Console and Analytics access, if you have them
Content
- A list of pages: keep, drop, rewrite, add
- Which text you will supply, and who writes it
- Photos and other images, at the largest size you have
- Documents or downloads that must carry across
Functionality and addresses
- Forms, bookings, payments, member areas and integrations: what each does and what must keep working
- The web addresses that matter most, and where they are used
Brand and direction
- Vector logo, colours and fonts
- Your goals, and what bothers you about the current site
- Two or three sites you like, with a note on why
- Who sends content, and who approves the result
Common mistakes
- Sending passwords in plain email. Use a secure route instead.
- Not deciding what to drop. Old pages and duplicates get carried over by default, or are lost by accident.
- Forgetting the quiet functions. A form that emails your bookkeeper is easy to overlook until it stops.
- Ignoring old addresses. If the new structure is not mapped to the old one, visitors reach error pages.
- Sending only a PNG or JPG logo.
- Using low-resolution images from the web, or images you have no right to use.
- Leaving the content until after the design. A layout built around placeholder text usually needs rework.
- Having no single decision maker. Feedback from several people at once often conflicts.
- Expecting a ranking promise. No one can honestly give one.
How we can help
If your site is live and you want it redesigned, our website redesign service keeps the content, systems and old addresses that already work. We build the new site on a private copy that you approve before go-live. You do not need the full pack to get in touch: send your site address and what you want to change, and we will say what else we need. We quote from your brief, itemised by task. See how we quote and how a project works.
More guides: WordPress plugin or custom code, logo file formats, or all our guides.
Have a project in mind?
A new website, a shop, a design refresh or a feature your site is missing: tell us a little about what you need and we will talk through the options.