Website Planning: What to Settle Before Design

Most website projects go wrong in the first meeting, and nobody notices for six months. Everyone agrees the current site feels dated, somebody pulls up three sites they like, and the agency goes away to make a homepage mockup. From that moment the project is about how the site looks, and every hard question gets answered by whatever the mockup implied. Which pages exist. What a visitor is supposed to do. Where the form goes. What happens to the pages that were quietly earning calls. Those get decided late, by accident, when changing the answer means redoing work.

I am the CEO of Killerspots. We plan and build websites for businesses across the country, and we take over a lot of sites that were designed before they were planned. This guide is the planning work we do before any design starts, in the order we do it, written for the owner who has to sign off on it. None of it requires a design tool. It requires a spreadsheet, your Search Console login, and an honest hour with whoever answers your phone.

What is website planning, and why does it come before design?

A website is a system that turns a visitor into a call, a form or a booking. Design is the surface of that system. When the surface gets built first, the system underneath gets whatever shape the surface allows, and the owner finds out at launch that the site is beautiful and the phone is quiet.

The planning phase is where the system gets its shape. It answers a short list of questions, and the answers become the brief the designer works from. None of it is glamorous, and all of it is cheaper to decide now than to discover later. The sections below take the questions in the order that matters. If you are replacing a site that already exists, the planning is the same with one extra job, protecting what you have, and that job is big enough that we wrote it up separately in our guide to website redesign. This guide is the plan itself.

What should the website produce, and how will you count it?

“We need a new website” is an expense, not a goal. The first planning decision is what the site exists to produce, in one sentence, with a number attached that you can read off a report. For most of the service businesses we build for, that sentence is some version of: more booked jobs from people who found us online. Calls, form fills and bookings are the outcomes. Visits, time on page and bounce rate are weather.

Once the outcome is named, decide how it gets counted, because the counting rules shape the build. If calls are the outcome, every phone number on the site needs to be tracked, and the rule for what counts as a lead needs to be written down. We audit a lot of accounts where the call counting quietly discards real customers because a duration threshold was set once and never revisited, and the owner has been told for a year that the site produces fewer leads than it does. If forms are the outcome, the form has to land somewhere that records the source page. If bookings are the outcome, the booking tool has to report back.

Plan the tracking now, not after launch, for a plain reason: the first month after a new site goes live is the only clean baseline you will ever get. Spend it without tracking and you have a site and an argument about whether it is working. Our standing rule on paid traffic is no spend until tracking is proven, and the same rule applies to the site that traffic lands on.

Who is the site for, and what do they already know when they land?

Audience planning usually produces a paragraph about demographics that nobody reads again. The useful version is narrower. Picture one person, at the moment they decide to look you up, and write down what they already know and what they are trying to settle. A homeowner with water on the kitchen floor at 9 PM knows she needs a plumber and is deciding whether you answer. A practice manager comparing three agencies knows what the service is and is deciding whether you have done it for someone like her. Those two people need different first screens, and a site that tries to greet both at once greets neither.

Then plan for how they arrived, because arrival changes what the page has to do. Someone who clicked an ad was promised something specific and should land on a page that keeps that promise, which is why ad traffic gets landing pages rather than the homepage. Someone who found a service page through search wants the answer to the question they typed and then a way to act. Someone sent by a friend already trusts you and mostly needs the phone number.

The cheapest research in this entire process is a conversation with the person who answers your phone. Ask what callers ask in the first thirty seconds. Do you serve my town. Do you take my insurance. How soon can you come out. Are you licensed for this. Every one of those is a page, a section or a FAQ entry the plan should include, in the words customers use rather than the words on your business card. We do this on every discovery, and it beats any keyword tool for the pages that actually close.

What do you already own that the plan has to protect?

If you have a site today, it is earning something, even if it does not feel like it. A services page ranks for a term you never targeted. Two old blog posts bring in a steady trickle of calls. A location page owns your town. The plan’s first job is to find those pages, because a new site is the most common way a business erases its own search traffic, and the owner usually blames the economy.

The method is not complicated. Open Search Console, pull the pages report for the last three months, sort by clicks and then by impressions, and the top of that list is the inventory the plan has to protect. Each of those pages gets a decision written next to it: keep at the same address, or redirect permanently to the page that replaces it, with the content that earned the ranking carried over rather than rewritten to sound fresh. That decision list becomes the redirect map, and the redirect map is a planning deliverable, not a launch-day scramble.

We relearned the cost of skipping this on our own site in October. A round of title rewrites and trims across pages that were already ranking cut our organic clicks roughly in half within a few weeks. Positions and click-through fell on the exact searches those pages used to win. The fix was not a cleverer title. It was restoring the versions that had been ranking, and we now lock the title, description and heading on any page with real impressions so that nobody, including us, changes them without a reason and a read-back date. If that can happen to an agency that does this for a living, it can happen to a business that just wanted a fresh look. Plan the protection first.

The second thing to protect is ownership. Before design starts, confirm the domain, the DNS, the hosting account and the CMS owner login are all in your business’s name, with any agency added as a user you can remove. We inherit sites where the owner cannot change a phone number because the only login belonged to a designer who stopped answering email. Fixing that in the plan is a checkbox. The full list of ownership questions is in our guide to how to choose a web design agency.

Which pages does a service business actually need?

The page list is where plans either get disciplined or get bloated. The rule that keeps it honest: a page exists because a real visitor searches for it or needs it to decide, not because the org chart has a box for it. Your site structure should follow how customers think about their problem, not how you think about your departments.

For a service business that produces a predictable list. Each service you sell and want to rank for gets its own page, written to answer the questions that service’s callers ask, because a single “Services” page listing nine things ranks for none of them. Each town or area you genuinely serve gets a page only if you can say something true and specific about working there, since a set of near-identical town pages with the city name swapped is both a poor experience and exactly the pattern search engines now treat as spam. A homepage that routes the three kinds of visitor from the section above to the right place quickly. Proof: reviews, projects, before-and-after work, the people. A contact page that is a phone call and a short form on mobile, not a map and a paragraph. And the pages your Search Console inventory says you cannot lose.

What the list does not include is everything else, and that is the hard part of the meeting. We took over a roofing client’s content library that had grown to more than two hundred blog posts over the years, and the handful of service and town pages were earning the calls while most of those posts earned nothing. Cutting the library down and putting the effort into the pages that matched real searches moved the account more than any new post would have. Plan the pages that have a job, and let the rest go.

Write the page list down as a one-page sitemap with the primary action named for each page: call, form, book, read next. That document, plus the redirect map, plus the content assignments in the section below, is most of a website plan.

What happens after someone fills out the form or calls?

This is the planning question the design-first projects skip entirely, because it is not design, and it is the one that decides whether the site pays for itself. The form is not the finish line. It is a handoff, and the plan has to say where the handoff goes and how fast.

The lowest version is a form that sends an email to the office. It works until the email lands at 4:50 on a Friday and nobody opens it until Monday, by which time the homeowner has hired the second company that called back. The version that pays is a form that drops the contact into a CRM with the page it came from, triggers a confirmation to the lead and an alert to your team, and starts a follow-up sequence if nobody responds. Missed calls get a text back within a minute. Chat gets answered. Everything is in one inbox with a record of who said what. We wire every site we build into KillerConnector for exactly that reason, and the wiring is specified in the plan because it changes the forms: which fields, which routing, which confirmation.

Planning this early also surfaces the questions that otherwise show up at launch. Who gets the alert at night. What happens to a lead from a town you do not serve. Where the booking tool lives. Whether the phone is answered by a person, an AI voice agent after hours, or voicemail, and what the site should promise about response time given the honest answer. The math on why minutes matter is in our post on speed to lead, and the cheapest fix for the calls you miss is in missed-call text-back. Both are plan items, not add-ons.

Who is writing the words and shooting the photos?

Ask any agency why a website launched late and the honest answer is almost never the build. It is the copy that did not arrive, the photos that never got taken, the approval that sat for three weeks. Content supply is the schedule, and a plan that does not assign it has not scheduled anything.

So assign it. For each page on the sitemap, who is writing it, from what source, by when. For each page that needs images, who is shooting them and when, and what gets used if the shoot slips. Decide now whether the words come from your team, from the agency’s writer after an interview with the person who does the work, or from a mix. The interview route is the one we use most, because the knowledge is in the owner’s head and the discipline of turning it into pages that answer real questions is a job, which is why we wrote a separate guide to website content writing. What does not work is writing the copy after the design is approved, because then the words get trimmed to fit boxes that were drawn around nothing.

Photos deserve the same line on the plan. Real photos of your people, your trucks, your work and your building outperform stock on every page that is supposed to build trust, which is most of them. A half-day shoot planned in week one solves it. We have our own studio and crew for the clients who want it handled, and the point stands for anyone: a site planned around photos that do not exist yet ends up with stock, and stock reads as stock.

Here is the test we apply to any wireframe before design goes further. Read it with the real headline and the real first paragraph dropped in. If it still works, design can proceed. If it only worked with placeholder text, the layout was decorating an empty page, and the plan has a content problem to solve first.

How do you plan for Google and AI answers at the same time?

A planning conversation in 2026 has to account for the fact that a growing share of your future customers will read an AI-generated answer before, or instead of, clicking a result. The good news is that planning for it is not a separate project. The pages that get cited in AI answers are the pages that answer a specific question clearly, carry something only that business could say, and name who wrote them. That is the same page that ranks.

So the plan specifies it at the page level. Each service page answers the questions its callers ask, in headings that read the way people ask them, with a short, definite answer under each heading before the detail. Each page carries at least a few things a competitor could not copy: how you actually do the work, what you turn down, what it is like to be your customer. The author is a real person at the business with a real role. The site loads fast on a phone, which is a build decision made now, not an optimization made later. And the technical foundation, structured data, clean URLs, a sitemap, an accessible crawl, is built in from the first page rather than retrofitted. We build every site with that foundation and run the ongoing content side through SEO and AIO for the clients who want it managed. For the plan, the point is simpler: there is no secret file that makes AI engines like you. There is a page that answers the question better than the other pages, and the plan decides which questions.

Which platform should the plan pick, and who edits it after launch?

Platform decisions go wrong when the agency’s habit makes them: a proprietary system only it can edit, or the one platform it knows applied to a business that needed five fast pages and a form. The plan avoids both by deciding from the job.

We build on WordPress, on Astro and custom, and the choice is made during planning. A business whose team posts weekly, needs specific plugins and wants to edit anything themselves goes on WordPress. A marketing site where every tenth of a second matters for ad quality scores and search goes on a static build, with the honest caveat that routine edits may need a developer. A genuinely unusual requirement gets custom work. Then the plan writes down the after-launch reality: who can change hours, add a service, fix a typo and publish an update, and whether that is you, your office manager or a maintenance plan. A site nobody can edit goes stale by spring.

Hosting belongs in the same decision. Where the site lives, what the hosting includes, who watches it at 3 AM, who runs updates and backups. We host and maintain the sites we build because a hacked or crashed site costs more in one bad week than a year of care, and the details of what that should cover are on our managed hosting page. For the plan, the question is just: who owns uptime after launch day, and is it written down.

What does the web design process look like once the plan is done?

With the plan in hand, the web design process is a sequence rather than a negotiation, and it is worth knowing the shape so you can tell when a project is on track.

Discovery produces the plan. Design turns the page list into layouts, starting with the pages that carry the most weight, usually the homepage, a service page template and the contact flow, reviewed with real copy in them. Build turns approved layouts into a working, mobile-first site on the chosen platform, with speed treated as a target measured in a score rather than a feeling. Then the leads get wired: forms, calls, chat and tracking connected to the CRM and tested end to end. Then QA, launch and the first weeks of reading real data and fixing what it shows.

Timelines on our builds run one to two weeks for a campaign landing page, four to eight weeks for a standard business site of roughly five to fifteen pages, and eight to sixteen weeks for a multi-location site with thirty or more pages. Those numbers assume the content arrives when the plan says it will. Nearly every project that runs long runs long on copy, photos and approvals, which is the reason the content assignments sit in the plan with dates next to them.

One more thing the process should include, because it rarely does: a review of the design against the plan before build starts. Does every page still have its stated action. Did the redirect map survive the new navigation. Is the form still going where the plan said. A twenty-minute check at that point saves the rebuild that happens when someone notices at launch.

What belongs on the launch checklist?

Launch day is where good plans get wasted by a missing hour of checking. The checklist is mostly the plan read back as tests.

Walk the redirect map. Every old address that earned traffic should land on its replacement, not on a generic page and not on an error. Submit every form and go find each submission in the CRM with the right source and the right alert fired. Dial every phone number from a phone. Trigger the tracking events that count the outcome you chose and confirm they fire once, not zero times and not twice. Run the speed test against the live address on a phone connection. Submit the sitemap and confirm the search tools see the new site, with the staging address blocked so nobody indexes two copies.

Then watch. For the first two weeks after launch, somebody reads traffic and leads daily against the baseline from the old site. A drop in a page that used to rank gets looked at that day, because a redirect that quietly failed is recoverable in a week and expensive in a quarter. We keep a watch on every site we launch for exactly this window, and the most common catch is not a broken page. It is a form that works perfectly and lands in a folder nobody opened.

When do you not need a full website plan?

We talk businesses out of full website projects regularly, and the reasons repeat. The first is the business with one offer and one campaign. It does not need a twenty-page plan, it needs a landing page built around that offer, live in two weeks, measured against the ads sending traffic to it. Building the whole site first delays the campaign by a quarter for no gain.

The second is the site whose structure is fine and whose problem is somewhere else. The pages rank and the copy says nothing. The forms work and nobody follows up. The phone rings and gets answered badly. A new site fixes none of that, and the honest plan is targeted work: rewrite the copy, wire the follow-up, fix the phone. We audit before we quote, and we say so when a rebuild is not the answer.

The third is the business that cannot supply content yet. No photos, no one available to be interviewed, no decision on which services to lead with. Planning the site before planning the content produces a design that waits. Plan the content first, then the site falls into place.

And the fourth is simply scale. A five-page service site needs a plan, but it needs the one-page version: the outcome, the page list with an action per page, where the form and the phone go, who writes and shoots what, and the redirect map if an older site exists. That takes an afternoon, and it is most of the difference between a site that exists and a site that works.

How Killerspots plans a website

Every website we build starts with the planning work above, done with the owner before a designer touches it: the outcome and how it will be counted, the visitor and how they arrive, the current traffic by page and the redirect map that protects it, the page list with an action on every page, the lead flow into KillerConnector with follow-up in minutes, the content assignments with names and dates, the platform chosen for the job, and the launch checklist. Then design, build, wiring, launch and the two-week watch. The copy comes from an interview with the people who do the work, the photos and video come from our own in-house production, the site ships mobile-first with a measured speed score and the foundation for search and AI answers built in, and we host it and keep it current afterward. We do this for businesses nationwide, and for companies in our home market through our Cincinnati web design team.

That is what our web design agency work looks like, whether the project is a multi-page business site or a single landing page for one campaign. If you are about to start a website project and the first deliverable you have been shown is a homepage mockup, stop and plan first. If you would rather have it planned with you, get in touch. The first conversation is the discovery, and sometimes it ends with us telling you that you do not need a new site yet. That is a good outcome too.