Questions to Ask When Redesigning a Website
A redesign replaces a site that already earns visits, inquiries or sales, so the first questions belong to the people who own it, not to a designer. Work through them with whoever pays for and runs the site before a brief goes out, and carry the ones nobody can answer to the agency or developer quoting for the work. The six groups run from the reason for the project and what the current site does well, through search traffic, content and platform, to money, dates and who decides.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Why now
Why are we redesigning the website now, and what happens if we wait a year?
Why ask it
A good answer names something that is costing money or blocking a plan: a platform going out of support, a rebrand, inquiries falling. If the honest reason is that the team is tired of looking at the site, remember that customers see it far less often than you do, and a smaller refresh may be enough.
What should the new site do for the business that the current one cannot?
Why ask it
Write the answer as things a visitor could do, such as book without calling or get a price without waiting for an email. Anything on that list the current site could manage with a week of work is a fix to make now, not a reason to rebuild.
Which number has to move for the redesign to count as a success, and where does it stand today?
Why ask it
Pick one main measure, such as inquiries a month, online orders or demo requests, and record today's figure before anyone opens a design file. Without a starting number, the only verdict available after launch is whether people like the look.
Would fixing a handful of pages get us most of the result without a full redesign?
Why ask it
Ask this yourselves, because a company that sells rebuilds has little reason to raise it. If the trouble sits in the home page, one form and the phone layout, repairing those three is cheaper and puts nothing else at risk. A full redesign earns its cost when the structure, the platform or the brand has to change.
Who is the site mainly for, and has that changed since the current version was built?
Why ask it
A site built for the customers of five years ago may be talking to the wrong people now. Name the two or three kinds of visitor who matter most and what each comes to do, then keep that list beside every design review so disagreements are settled by it and not by taste.
What do customers, the sales team and support say is wrong with the site?
Why ask it
Collect these before the kickoff: the questions people call to ask because they could not find the answer, the page sales staff avoid sending, the form support keeps apologizing for. A complaint heard three times from outside the building outranks any opinion from inside it.
What do competitors' websites make easier for a customer than ours does?
Why ask it
Visit three of them as a buyer would and try the same task on each: get a price, book a slot, find a phone number. Write down where theirs took fewer steps than yours. Copying how they look is another matter and seldom helps, since you cannot see whether their design earns them anything.
Is the brand changing at the same time: the name, the logo, the message or the prices?
Why ask it
A rebrand and a redesign in one project stack two sets of decisions on the same people and make it hard to tell afterward which change moved the numbers. If both have to happen, settle the brand first and get it approved, so the site is built once.
What did we learn the last time this site was redesigned?
Why ask it
Someone usually remembers what ran over: the copy that arrived late, the executive who first saw the design the week before launch, the traffic that dipped. Whatever went wrong then tends to go wrong again unless someone is made responsible for it this time. If nobody on the team was there, ask whoever built it.
What works
Which pages are earning the leads and sales we get now?
Why ask it
Open the analytics and list the ten pages where the most conversions start or finish. Treat those as protected: redesign them last, change them least, and compare them one by one after launch. A plain page that converts is worth more than a handsome one nobody has tested.
Where do our visitors come from: search, ads, email, social, referrals or typing the address?
Why ask it
The split decides how careful the project has to be. A site fed mostly by search has the most to lose from changed addresses and rewritten pages, while one fed by ads and email can change more freely as long as its landing pages keep working.
Which pages do people arrive on first, and how often is that not the home page?
Why ask it
Design meetings tend to circle the home page, yet on many sites a large share of visitors come in through a service page or an article and never see it. Look at the top landing pages and make sure each can stand alone: who you are, what the page offers and what to do next.
Where do people give up in the contact form, the checkout or the booking steps?
Why ask it
If the analytics can show drop-off step by step, find the step that loses the most people and ask what it demands of them. Fixing that one step is often a cheaper win than the whole redesign, and it shows the designer which part of the new site to try out on real customers.
What share of visits comes from phones, and do phone visitors convert as well as desktop ones?
Why ask it
Compare the conversion rate on each device, not only the visit counts. A wide gap suggests the phone version is where the redesign should start, and that every design should be reviewed on a phone in the hand before anyone sees it on a big monitor.
Is conversion tracking working correctly today, and will we have clean numbers from before the launch?
Why ask it
Check it by filling in each form and placing a test order, then looking for every one of them in the reports. Broken tracking discovered after launch leaves nothing to compare against. Repair it now and let it run for some weeks, longer if your business is seasonal.
Which parts of the current site would regular customers miss if they disappeared?
Why ask it
Think of what people come back for: a price list, a login, the business hours, a calculator, a PDF that gets passed around. These rarely look impressive in a design review, so they get dropped by accident. List them and check each one off against the new sitemap.
How quickly do our main pages load now, on a phone as well as at a desk?
Why ask it
Run the home page and two pages that bring in sales through a free speed test and save the results. A new design often brings bigger images and more scripts, so put a target in the brief: no slower than today on the same test. A redesign is also the cheapest moment to drop old chat widgets, pixels and plugins nobody looks at.
Search
Which pages rank for the searches that bring us customers?
Why ask it
Your search engine's report for site owners (Search Console, on Google) lists the queries and the pages that answer them. Mark the pages holding those rankings and tell whoever rewrites the copy that the topic, the headings and the main phrases on them stay unless there is a reason. A page rewritten for style alone can lose the words it was found for.
Will the page addresses change, and who is writing the redirect map?
Why ask it
Every old address that changes needs a permanent redirect to its closest new page, written out in a spreadsheet with one row per address. Agree on a named owner for that sheet before the build starts. If you are told the platform takes care of it, ask to see the sheet anyway.
Which of our pages have links pointing at them from other websites?
Why ask it
Links from other sites are slow to earn and easy to waste: remove the page they point to and the visitor lands on an error. Export the list of linked pages from that same search report or a link-checking tool, and give each one either a place on the new site or a redirect to its nearest match.
If we merge or delete pages, where do the searches they answered go?
Why ask it
For each page on the cut list, look up what it was found for over the past year. If that is nothing, let it go. If it is something you still sell, move the useful part into the page that survives and point the old address there, not at the home page.
Do the page titles, descriptions, headings and structured data carry over to the new templates?
Why ask it
These live in fields that a new theme can quietly reset to defaults, leaving every page titled with the company name. Ask how they will be moved, and spot-check twenty pages on the staging site against the live one before launch.
How is the unfinished site kept out of search results, and who removes that block on launch day?
Why ask it
Hiding a staging site behind a password or a no-index setting is right. The accident to guard against is that setting going live with the site, after which pages start dropping out of search. Put its removal on the launch checklist with a name beside it, and have a second person confirm.
Are we changing the domain name or moving sections between subdomains as part of this?
Why ask it
A new domain on top of a new design and new addresses is three changes at once, and if traffic falls nobody can say which one did it. Where there is a choice, move the domain as its own step, some months apart. Where there is none, ask the agency how many domain moves it has handled and how they went.
Which ads, email templates, QR codes and printed materials point at pages that are about to move?
Why ask it
Search engines are not the only things holding your old addresses. Go through running ad campaigns, automated emails, invoices, packaging and social profiles, and update or redirect each link. An ad sending paid clicks to an error page keeps spending for as long as nobody notices.
What will we check in the first weeks after launch, and how big a drop would make us act?
Why ask it
Settle the watch list now: crawl errors, positions for the ten main phrases, and search visits and conversions week by week. Some movement after a relaunch is common, so agree beforehand what counts as a problem and who has time set aside to chase it. Otherwise the alarm is raised a month late.
Content
How many pages does the site have, and when did anyone last list them all?
Why ask it
The guess is often low, because old campaign pages and blog posts are easy to forget. Export the full list from the sitemap, a crawl or the platform itself, with visits beside each address, before anyone quotes for moving content. That count sets the size of the job.
For each page, do we keep it as it is, rewrite it, merge it or remove it?
Why ask it
Add a column to the page list and put one of those four words in every row, with the name of whoever decided. It is dull work, and it settles arguments that would otherwise surface halfway through design. A page with visits or rankings needs a stated reason before it is marked for removal.
Who is writing the new copy, and how many hours a week do they really have for it?
Why ask it
Late content is a common reason launch dates slip, and the delay usually sits on the client's side of the table. If the writer already has a full job, cut the number of pages being rewritten, pay for a copywriter, or move the date now while moving it is cheap.
Which pages can we supply finished text and photos for before design starts?
Why ask it
A layout drawn around three tidy lines of filler breaks when the real paragraph runs to nine and the real photo is a tall shot of a warehouse. Aim to hand over final copy for the home page and one of each page type, even if the rest follows. Large layouts also show up small or dated photos, so find out early whether a shoot is needed.
What happens to the blog archive, the PDFs and the other downloads?
Why ask it
Old posts and files slip off the plan because nobody opens them in meetings. See which still get visits or links, move those, and decide whether the rest are redirected or retired. File addresses often change with a new platform, so they need rows in the redirect sheet too.
Which pages need approval from legal, compliance or the owner before they go live?
Why ask it
Prices, guarantees, terms, privacy wording and anything regulated in your line of business usually have a specific person who must read them. Ask that person now how long a review takes and what they need to see, since the rules depend on your industry and where you operate. Then give the review its own line on the timeline.
How should the main menu be organized, and are the labels our words or the customers'?
Why ask it
Internal names for departments and product lines mean little to someone arriving from a search. Draft the menu from the tasks visitors come to do, then show it to three customers and ask where they would click to find one particular thing. Do it before design, since the menu shapes every page.
Platform
Do we stay on the platform we have or move to another, and what is the case for each?
Why ask it
Moving adds cost, a data migration and retraining, so there should be a named thing the current platform cannot do. Be a little wary when the recommended one happens to be the only one the agency builds on, and ask what it would advise if it worked with both.
What does the site connect to today: the CRM, the email list, payments, booking, inventory or live chat?
Why ask it
Walk through the site as a customer and write down every point where information leaves it or arrives, including which inbox each form reaches. Every connection is a line in the quote and a test on launch day. The ones nobody remembers, such as a form that quietly adds people to a newsletter, are the ones that break.
Who will edit the site week to week, and can they add a page or a campaign landing page without a developer?
Why ask it
Have the people who will do the editing try the editor on a demo before the platform is chosen. Give them a real task, such as building a page for next month's offer. If they need help in the demo, they will need paid help every month after launch.
What data has to move across: products, customer accounts, order history, members or past form entries?
Why ask it
Ask how each kind will be moved, whether by an import tool or by hand, and who checks the result. Customer logins deserve a separate question, since passwords may not carry over and people would have to reset them. If so, plan the email that warns them.
Can we log in today to the domain registrar, the DNS, the hosting and the analytics, or does a former supplier hold them?
Why ask it
Try each login this week. Launch day needs the DNS, and that is a bad moment to learn the account belongs to a freelancer who stopped answering years ago. Move every account to an email address the company controls before the project starts.
Once the builder's work is done, who handles updates, backups and security, and is that in the price?
Why ask it
A site with nobody assigned to it soon falls behind on updates, which is when forms stop working and break-ins get easier. Get the arrangement in writing: what is covered, the monthly or yearly fee, and how fast someone answers when the site is down. If the job falls to your own team, make sure they have the logins and the hours.
How will the new site work for people using a keyboard, a screen reader or enlarged text, and what standard is the builder held to?
Why ask it
What the law requires depends on where you do business and what kind of organization you are, so ask an adviser who knows your situation instead of taking a designer's word. Either way, name the standard in the contract and ask how it will be tested. Building it in tends to cost less than repairing it after launch.
What tracking, cookie banner and consent setup does the new site need?
Why ask it
List every tag on the current site and what it is for, then decide which come along. Privacy rules differ by country and state, so ask whoever advises you what applies to your visitors. Keep the same analytics account running through the switch, or the before and after numbers will not line up.
Project
What is the total budget, and what does it have to cover beyond design and build?
Why ask it
Copywriting, photography, the content move, redirects, licenses, training and a few weeks of fixes after launch are the items most often missing from a first figure. Give each its own line, ask for the yearly running cost beside the build price, and tell the agency the real number so the proposal fits it.
What launch date are we working toward, and is it tied to anything real?
Why ask it
A trade show, a product release or a contract ending is a real deadline, and the scope should shrink to meet it. A date chosen because it sounded reasonable can move. Whichever it is, avoid launching just before your busiest season: you want quiet weeks for finding problems.
Who gives the final sign-off, and who is consulted but does not decide?
Why ask it
Name one person, and make sure the owner or executive who could overrule them sees the work at the sitemap and first-design stages, not the week before launch. A late opinion from the top is among the more expensive events in a web project. Write both lists down and share them with the agency.
Who leads the project on our side, and how much of their week is set aside for it?
Why ask it
An agency moves only as fast as its answers arrive. The lead gathers everyone's comments into one reply per round, settles the contradictions before sending it, chases content and makes small decisions without a meeting. If no hours are freed up for that, the timeline stretches by however long the questions sit.
Do we build it with our own team, hire a freelancer or bring in an agency?
Why ask it
A new look on the same platform may suit an in-house team or one good freelancer. A platform move with integrations and a large content migration needs several skills at once, which is what an agency charges for. Whoever you lean toward, find out which parts they pass on to someone else.
Which of the agency's past redesigns can we look at, and what happened to those sites' traffic and leads afterward?
Why ask it
Ask for a redesign of an existing site, not a brand-new build, since keeping what already worked is the harder skill. A reference call with that client should cover whether search traffic held, whether the date was met and what the agency was like once the last invoice was paid.
If we later part company with the builder, what stays with us: the site, the design files, the licenses, the accounts?
Why ask it
Arrangements differ from one agency and platform to the next: a theme may be licensed and not owned, and the site may sit in the agency's hosting account. Read what the contract says before signing, and ask how a handover to another team would work. Anything unclear is a question for someone who reads contracts for a living.
If the budget or the date gets tight, which features are cut first?
Why ask it
Rank the wish list before the pressure arrives: needed at launch, wanted soon after, nice someday. Decided calmly, the order follows what earns money; decided in the last two weeks, it follows whoever objects loudest. Get the second phase priced and dated, or it tends not to happen.
Will real customers try the new design before it is built, and who sets that up?
Why ask it
A handful of people from outside the company, each given one task on a clickable draft, will show where the menu or a form trips them up while a change still costs an afternoon. Find out whether sessions like that are in the quote. If they are not, a few willing customers and a shared screen are enough.
What does the pre-launch test list cover, and who on our side works through it?
Why ask it
The builder tests that the site works, and your team tests that it is right. Have someone who knows the business place an order, send every form, read the prices and try it all on an older phone. Hand them the protected pages and the redirect sheet, and several clear days before the date.
What is the plan for launch day: when, who is on hand, and how do we go back if it fails?
Why ask it
Early in the week and early in the day leaves working hours to fix what turns up. Ask how long the old site stays available, whether a backup is taken that morning, and who has the authority to roll back. Friday afternoon launches are how a broken checkout lasts a whole weekend.
When do we compare the new site with the numbers we saved before launch, and who calls that meeting?
Why ask it
Put two dates in the calendar now, roughly one month and three months after launch, to set the new figures against the baseline. The first meeting is for fixing what broke. The second is for judging the redesign against the one number you chose at the start.
How to work through the questions before a redesign
Practical guidance for the conversation itself
Before a brief is written
Answer Why now in one paragraph
Take the first group to whoever is paying for the project and write the answers down as a single paragraph: the reason, the one number, and what stays out of scope. If that paragraph cannot be agreed, the project is not ready for an agency, and finding that out costs an hour instead of a deposit.
Pull the numbers before the opinions
Work through What works and Search with the analytics and the search query report open, before the first meeting about how the site should look. Save the reports as files with the date in the name. Once a design is on the screen, people stop asking what the old site did well.
Put each group to the person who knows
The owner, or whoever holds the budget, answers Why now and Project. Whoever runs marketing answers What works, Search and Content. The Platform questions go to the person who manages the current site, even if that is an outside freelancer, and an hour of their paid time is money well spent.
Build the page list once
One spreadsheet with a row for every address does several jobs: the content decisions, the redirect map, the protected pages and the pre-launch test. Start it in the first week and keep a single copy. Three versions in three inboxes is how a page with rankings gets dropped.
Taking the list to an agency or developer
Send your answers with the request for a quote
A proposal written against real answers, such as the page count, the integrations, the protected pages and the date, can be compared with another one. A proposal written against 'we need a new website' is a guess, and the gap shows up later as extra charges.
Ask who does the search work
Put the Search group to each candidate and ask who, by name or role, builds the redirect sheet and checks the site after launch. Some agencies include it, some assume you have someone, and some have not thought about it. Whichever it is, have it written into the scope.
Keep the questions that are yours
An agency can tell you what a platform costs or how long a migration takes. It cannot tell you why you are redesigning, what the site is for or who signs off. When a team hands those questions over, the answers come back shaped like whatever the agency sells.
Open every review with the same sheet
Start each design review by looking at the success number and the protected pages, then at the design. It takes two minutes and it changes what people comment on: less about the shade of a button, more about whether the inquiry form is still easy to reach.
From sign-off to the first three months
Freeze, back up, then switch
A few days before launch, stop editing the old site so nothing written in the gap is lost. Take a full backup that morning, confirm who can restore it, and keep the old site reachable at a private address for a while, since someone will want to see how a page used to read.
Test the redirects twice
Run the old address list against the staging site before launch and against the live site right after. Every row should land on a working page on the same subject as the old one. Fix the misses that day, while everyone still remembers what moved where.
Compare like with like
Judge the result against the same weeks of the previous year where you can, or against the saved baseline, and give it a full month before drawing conclusions. The first week mixes launch-day faults, curious staff and search engines recrawling, and tells you little.
Hold back a little budget
Real visitors find things no test list did. Keep some money and some of the builder's time for the first weeks, agreed in advance, so fixes are made promptly and nobody has to open a new negotiation over a broken form.
Where redesigns go wrong
Starting from the look
Mood boards and competitor screenshots are the enjoyable part, so projects begin there. A site that is prettier and brings in fewer inquiries has failed, and that outcome is likeliest when nobody wrote down what the old one was doing right.
Changing everything at once
A new design, platform, set of addresses, copy and domain in a single launch means that if results fall there are five suspects. Where you can, hold something still: keep the addresses, or keep the copy on the pages that rank, and change those later.
Treating content as the last step
Design gets approved, the build is finished, and then the site waits for words. Start the writing when the sitemap is agreed, alongside design. If that cannot be done, launch with the existing copy on most pages and rewrite in rounds afterward.
Calling it finished on launch day
Sections with no named owner go stale first, and a stale site is what prompts the next redesign. Put a person, not a department, against each section, set a date for reviewing the numbers, and write down what the second phase contains.