Get In Touch
I have watched a lot of website builds go sideways, and almost none of them failed because someone wrote bad code. They failed because nobody agreed on what "done" meant until week nine.
That is the entire case for a website project plan. Not a Gantt chart built to impress a client, and not a folder of documents nobody opens after kickoff. A plan is the shared answer to four questions: what are we building, who decides, when does each piece land, and what happens when something changes. Get those right, and the build becomes almost boring, which is exactly the outcome you want.
PMI's research found that 52% of projects experienced scope creep or uncontrolled changes to scope, up from 43% five years earlier. Website work is unusually exposed to this, because the deliverable is visual and everyone in the building has an opinion about the hero section.
So here is the full website project planning process I use, stage by stage, including the parts most guides skip: template-based estimating, redirect mapping, buffer placement, real costs, and what happens after launch day. Keep it open on a second monitor while you plan your next build.
A website project is a time-boxed effort to design, build, and launch a new website or rebuild an existing one, ending with a live site that meets defined business goals. It has a start date, an end date, a budget, a team, and a set of deliverables. That last part separates it from ongoing website work, which never really ends.
Website projects come in four flavors, and the type you are running changes almost everything about how you plan it.
New build from scratch: No legacy URLs, no traffic to protect. Easiest to plan, hardest to estimate, because there is no baseline to reason from.
Redesign: The visual layer changes, but URLs and content mostly survive. Lower technical risk, higher stakeholder risk, since everyone gets an opinion on aesthetics.
Replatform or migration: A new CMS, new domain, or restructured URLs. Highest SEO risk of the four, and it needs its own sub-plan.
Rebuild: Design, platform, content, and structure all change at once. The most expensive kind, and the most likely to overrun, because you have stacked four risk profiles.
The same cast shows up regardless: a project owner who holds the budget, a decision maker who signs off, a designer, developers, someone accountable for content, and someone accountable for SEO and analytics. On small projects, one person wears three hats. The roles do not change, only the headcount.
The deliverable is not "a website." It is a website that does a specific job for a specific audience, measured against numbers you agreed on before anyone opened Figma. Our breakdown of the website design and development process walks through the same lifecycle from a delivery perspective.
Because a website is the only marketing asset where design, engineering, copywriting, SEO, legal, and sales all have to agree, and none of them share a vocabulary. The plan is the translation layer.
The failure pattern is boringly consistent. Design gets approved with placeholder copy. Development starts. Real copy arrives and does not fit the layout. Design reopens. Meanwhile the CFO sees the homepage in week ten and wants the value proposition changed. Nobody did anything wrong on any single day, and the project still slipped six weeks.
A written plan does not prevent surprises. It changes what they cost. Specifically, it gives you:
Website project planning is not administrative overhead. It is the cheapest insurance you will ever buy on a five- or six-figure asset.
This is the operational core. Twelve stages, each with the artifacts you should walk out with. You will not need every item on every project, but skip things deliberately rather than discovering in week eight that you never did them.
These stages overlap in execution. Content runs alongside design. SEO runs alongside everything. The order below is the order in which you should plan them, not a strict sequence of gates.
Everything downstream is an argument about priorities. Goals settle those arguments without anyone raising their voice.
Before anything else, write one sentence explaining why this project exists. "Our current site does not generate qualified demo requests from mid-market buyers" is a problem statement. "We need a modern website" is a feeling. If the room cannot agree on one sentence, you have found your first blocker on day one instead of day sixty.
Every goal needs a metric, a baseline, and a target with a date. "More leads" becomes "increase demo form submissions from 40 to 65 per month within 90 days of launch." Now design decisions have a tiebreaker. When someone proposes removing the sticky CTA because it feels cluttered, you have a number to point at.
Export everything before the rebuild begins: organic sessions by landing page, conversion rates by template, top pages by traffic and by backlinks, form completion rates. Take dated screenshots of your dashboards. Six months from now, this export is the only thing standing between you and a vibes-based argument about whether the redesign worked.
This one saves more time than it should. Write down the goals this project is not serving. "We are not building for enterprise buyers in this phase." Stated non-goals are the fastest way to kill a bad feature request politely.
Discovery replaces assumptions with evidence. It is also the stage most likely to get compressed into a single kickoff call when the timeline tightens.
That compression is costly. In a survey of 436 UX practitioners, Nielsen Norman Group found that many discoveries run too short, skip user research entirely, and fail to involve the right people. A discovery that only interviews the marketing team produces a website built for the marketing team.
Talk to six to ten people across sales, support, marketing, and leadership, individually, not in a group, because groups converge on the loudest opinion. Ask what customers ask them most often, what the current site gets wrong, and what would make them call the project a failure. That last question is the most useful one you will ask.
You do not need a lab. Five customer interviews surface more than a hundred-response survey. If budget is zero, mine what you already have: Search Console queries, site search logs, sales call recordings, and support ticket categories. The questions customers already ask are your information architecture, sitting there for free.
Do not collect screenshots of pretty homepages. Map how three or four competitors structure navigation, what sits on their service pages, how they handle pricing, and which pages rank for terms you care about. You are looking for conventions to follow and gaps to exploit, not a mood board.
Crawl the current site. Document CMS version, plugins, integrations, hosting, DNS, SSL, analytics, tag manager containers, and anything held together by a custom script someone wrote in 2019 and never documented. Find out who controls the domain registrar login now, not on launch day.
The scope document is the spine of the whole plan. If you write only one artifact from this guide, write this one.
Be specific enough to estimate. "Blog" is not a deliverable. "Blog index template, post template, category archive, author archive, migration of 84 existing posts" is a deliverable set. Every line should be something a developer could quote.
This is the section everyone skips and later wishes they had written. Out-of-scope lists are a communication tool, not defensive paperwork. "Multi-language is out of scope for phase one," said in week two, is a planning decision. Said in week nine, it is a fight. Write ten to fifteen lines here, and start with the obvious ones, because obvious things are what clients assume are included.
Every estimate rests on assumptions, so surface them. "Client provides final copy for all 22 pages by March 14." "The CRM has a documented public API." When an assumption breaks, you have a written record showing the estimate was conditional, which turns a blame conversation into a change order conversation.
Define done before you start. For a contact form: submits on mobile Safari, iOS Chrome, and desktop Chrome; routes to two specified inboxes; fires a GA4 event; validates required fields with visible error states; passes keyboard-only navigation. Now "the form is done" is testable rather than an opinion.
Architecture decisions are the most expensive ones to reverse, because they cascade into templates, URLs, navigation, internal linking, and analytics.
Export every URL into a spreadsheet with traffic, conversions, and backlink data attached. Assign each page exactly one verdict: keep, merge, rewrite, or kill. No fifth option, no "maybe." A 400-page site usually reduces to 120 pages worth carrying forward, and the 280 you cut were diluting your topical focus anyway.
Card sorting tells you how users group your content. Tree testing tells you whether they can find things in the structure you propose. Both run for under $200 with twenty participants. Skipping this is how you end up with navigation that makes perfect sense to the org chart and none to customers.
Here is the reframe that improves estimating accuracy more than anything else in this guide. Clients think in pages. Developers build templates. A 60-page site with 7 templates is a smaller build than a 20-page site with 14 templates, every time. Do the sitemap, then collapse it into a template list and estimate against that. Your numbers will stop being fiction.
Decide on trailing slashes, category nesting, date stamps in blog URLs, and whether service pages sit at root or under a directory. Changing this after content is loaded means rewriting your redirect map twice. While you are here, plan your internal linking and heading structure at the template level.
Content is the number one cause of website delays, and it is not close. One web design industry survey found that roughly 38% of designers name late or poor client content as the top reason projects slip. Not code. Not design. Copy that nobody wanted to write.
Not a team. A person, with a date. "Marketing will handle content" is how a project loses a month. A spreadsheet with page, owner, due date, and status is enough. What matters is that a human name sits next to every row.
For each template, specify the fields: H1, meta title, meta description, hero subhead with a character limit, body sections, image dimensions, alt text, CTA text, schema fields. Character limits are not bureaucracy. They are what stops a 90-character headline from breaking a layout designed for 45.
Assign primary and secondary keywords at the sitemap stage, not after pages are written. This prevents two service pages from competing for the same query, the most common self-inflicted SEO wound in a rebuild. It also means writers are briefed rather than guessing.
Content deadlines are milestones, not soft targets. My rule: design does not move to high-fidelity mockups until real copy exists for the homepage and one service page. Designing around lorem ipsum and retrofitting real words later is how you pay for the same design twice.
Platform choice is a ten-minute conversation that sets the next five years of maintenance cost. Treat it accordingly.
Not to what the dev team enjoys building in. If a two-person marketing team will publish weekly without developer help, that requirement outranks technical elegance. Ask who publishes a new page six months after launch, and what their comfort level is. If you are weighing options, our WordPress vs. Shopify vs. Webflow comparison breaks down how different platforms fit different use cases.
CRM, marketing automation, payment gateway, booking system, live chat, review widgets, analytics, consent management. For each, confirm three things: does a supported integration exist, is it one-way or two-way, and who owns the credentials. Integration surprises are the most common cause of mid-build re-estimation.
You need local, staging, and production at minimum. Staging must be password-protected, with a documented plan for how that protection is removed at launch. Decide who has deploy rights and where the repository lives. Write down who holds registrar, DNS, hosting, and CMS credentials, because chasing a former employee for a domain login during launch week is a specific kind of misery.
Add license fees, hosting, plugin subscriptions, transaction fees, and the developer hours needed for routine changes. A platform that saves $8,000 at build and costs $400 a month in fees is not cheaper. It is a loan.
Design is where timelines quietly disintegrate, because feedback has no natural endpoint unless you build one.
Low-fidelity wireframes let stakeholders argue about hierarchy and content priority without arguing about blue. Present them deliberately ugly, in grayscale, with boxes. The moment you add typography and imagery, feedback shifts to "can we try a different font," and you never get the structural conversation back.
Deliver a component library: buttons, form fields, cards, navigation states, typography and spacing scales, color tokens, and responsive behavior. Then design three key templates fully and assemble the rest from components. This is faster to build, cheaper to maintain, and the difference between a design that survives two years of edits and one that degrades by month four.
Two rounds is standard, three is generous. State plainly what counts as a round and what happens once they are used. Not as a threat, but as clarity. Clients respect a limit they knew about on day one and resent one that appears in week seven.
Forty-eight to seventy-two hours, one consolidated response, one voice. A 2025 survey of 500 marketing and creative professionals found that over 60% lose up to a full working day each week waiting on approvals, with 85% reporting timelines running past plan. Feedback arriving as nine emails across five days is the mechanism behind that number.
Development is the most predictable phase in a web development project plan, provided the earlier stages were done properly. When development is unpredictable, the cause is almost always upstream.
Global elements first: header, footer, navigation, design tokens, base components. Then templates, most complex first. Then content, integrations, and performance work. Building the homepage first feels good and is usually wrong, because it has the most one-off components and teaches you the least about the system.
Yes, show progress. But set expectations in writing: staging is a work in progress; it will look broken at times, and feedback on unfinished sections is not useful. Without that framing, you will spend hours answering bug reports about features that do not exist yet.
List browsers, devices, and test cases in advance. At minimum: Chrome, Safari, Firefox, and Edge on desktop; Safari on iOS and Chrome on Android. Then functional cases: forms submit and route correctly, CTAs link correctly, 404 works, embeds load, and the site is navigable by keyboard alone. Budget three to five business days. QA is the first thing squeezed when timelines tighten and the thing that most reliably damages your reputation when it is.
A bug is functionality not matching the agreed acceptance criteria. A change is new functionality. Write this down before QA begins, because during QA week every change request arrives labeled as a bug. That is not malice; it is just how it feels from the client side.
If you are replacing an existing site, this is the highest-risk stage in the project and the one most often handled in the final week. Plan it in the first two.
Google's own guidance is clear about sequence. Its site move documentation advises preparing and testing the new site, building a URL map from current URLs to their new equivalents, redirecting old to new, then monitoring traffic on both. For large sites, it recommends moving a portion first to observe the effect before committing the rest.
Run a full crawl of the live site and archive it. Export Search Console data for the last sixteen months, all indexed URLs, and your backlink profile. This archive is your reference point when something goes sideways, and something usually does.
One row per old URL, one destination per row, no exceptions. Prioritize pages with traffic, conversions, or backlinks, then handle the long tail with pattern rules. Google recommends permanent server-side redirects using 301 or 308, and advises against chains by pointing each old URL straight at its final destination. Test the map on staging, not after launch. Our guide to planning a web migration properly covers the topic in depth.
Title tags, meta descriptions, H1s, canonical tags, structured data, image alt text, hreflang where applicable, and internal link structure. A rebuild that ships beautiful pages with auto-generated title tags has discarded years of accumulated work for no reason.
The single most common catastrophic migration error is shipping a staging environment's noindex directive or blocking robots.txt to production. It costs nothing to prevent and weeks to recover from. Put it on the launch checklist as its own line, assigned to a named person, with a verification step that involves actually loading the file and reading it.
Most project delays are decision delays wearing a costume. Governance shortens the distance between a question and an answer.
For each major deliverable, name who is Responsible, Accountable, Consulted, and Informed. Exactly one Accountable person per row. The moment you have two, you have a committee, and committees do not approve things. They schedule follow-up meetings.
One person on the client side consolidates internal feedback and speaks with a single voice. They can gather input from twelve people. They must deliver one answer. Without this, you become the referee in an internal disagreement that is not yours to settle, on your hourly rate.
Weekly thirty-minute standing call, written recap within two hours, async updates in a shared channel between calls. The recap matters more than the meeting. It is a dated written record of what was agreed, and it prevents the week-nine conversation that begins "I thought we said."
This is the habit most often stolen from my process, and it is one shared spreadsheet: date, decision, who made it, rationale, and what it supersedes. When someone asks in week ten why the pricing page has no comparison table, you open row 34 and read the reason back. Fifteen seconds instead of forty-five minutes.
Now, and only now, do you put dates on things. Scheduling before scoping is how optimistic fiction gets written.
Decompose to tasks of roughly four to sixteen hours. Bigger and the estimate is a guess. Smaller, and you spend more time updating your project tool than working. "Build service template" is too big. "Build service template: hero, intro, three content blocks, CTA band, responsive breakpoints" is estimable.
For each uncertain task, capture an optimistic, most likely, and pessimistic estimate, then compute expected duration as (O + 4M + P) / 6. The formula matters less than the conversation it forces. Asking a developer what the worst case looks like surfaces risks a single number hides completely.
The critical path is the longest chain of dependent tasks. Delays on it move the launch date. Delays off it do not. On website projects, that path runs through content and approvals far more often than through code, which is why "the developers are behind" is usually a misdiagnosis.
This is the estimating point I argue about most. When you pad each task by 20%, the padding gets consumed, because work expands to fill available time. Estimate honestly at the task level, then hold one project-level buffer of 15 to 20% that you release deliberately and track. Buffer you can see is buffer you can defend.
A plan that ends at launch is half a plan. Going live starts the measurement period.
Not a checklist. A runbook: sequenced steps, each with a time, an owner, and a verification method. DNS change at 09:00, verified over a mobile network. SSL check at 09:15. Redirect spot-check on twenty URLs at 09:30. Sitemap submitted at 10:00. Launch mornings are stressful, and stress is not the moment to be remembering things.
Decide before launch week which issues block the launch and which get fixed after. A broken checkout blocks. A misaligned footer on one breakpoint does not. Confirm you can roll back: full backup taken, restore tested, and DNS TTL lowered a day ahead so a reversal propagates quickly.
I will die on this hill. Tuesday or Wednesday morning, with the full team available for the next forty-eight hours. Friday launches mean whatever breaks at 4 pm has the whole weekend to compound, unattended, while the person who can fix it is unreachable.
Daily for the first two weeks: crawl errors, index coverage, 404 logs, form submissions, Core Web Vitals. Then weekly for the quarter. Field data at the 75th percentile is what counts, as web.dev explains, so give real-user data several weeks to accumulate before judging performance. Compare against the Stage 1 baseline at day 30 and day 90, then feed everything deferred into a conversion rate optimization backlog.
Build complexity matters less than decision speed. I have seen a 40-page site launch in nine weeks with a responsive client, and a 12-page site take seven months because approvals went through a committee.
Here are ranges I would defend in a proposal, assuming a competent team and a client who responds within the agreed feedback windows.
| Project type | Typical duration | Templates | Biggest risk |
| Landing page or microsite | 2 to 3 weeks | 1 to 2 | Copy turnaround |
| Small business site (5 to 10 pages) | 5 to 8 weeks | 4 to 6 | Content readiness |
| Mid-size marketing site (10 to 30 pages) | 8 to 14 weeks | 7 to 12 | Approval cycles |
| Site with migration from an existing domain | 12 to 18 weeks | 8 to 14 | Redirect mapping |
| E-commerce build | 12 to 20 weeks | 10 to 16 | Product data and integrations |
| Enterprise or multi-language rebuild | 5 to 9 months | 15+ | Governance and stakeholders |
Several factors move these numbers, and it helps to quantify them rather than gesturing at "it depends":
Website pricing looks opaque because most quotes present a single number for a bundle of very different activities. Here is what sits inside that number and why each line exists. Ranges reflect small to mid-market projects in USD.
Typically 10 to 15% of the total: stakeholder interviews, user research, competitive analysis, technical audit, and the scope document. Clients sometimes push to cut it, since it produces documents rather than pixels. It is also what determines whether the other 85% gets spent on the right thing. Skipping discovery moves the cost into rework.
Usually 5 to 10%: sitemap, content inventory, card sorting, keyword-to-template mapping, content model. Small in the budget, disproportionate in influence. Every hour here removes several hours of design revision later, because structure disagreements surface before anything expensive gets built.
Roughly 20 to 30%: wireframes, high-fidelity mockups, a component library, responsive behavior, and prototypes where interaction needs explaining. The cost driver is unique template count, not page count, which is why the Stage 4 reframe matters commercially. Our guide to Figma UI/UX design cost breaks down the range.
Usually 30 to 40%, the largest single line: front-end build, CMS configuration, custom fields, integrations, forms, performance work, environments. Custom functionality expands this fast. A booking system, member area, or two-way CRM sync can each cost more than the rest of the site combined. Platform choice shifts the number too, as our WordPress pricing breakdown shows.
Highly variable and frequently excluded from quotes. Copywriting typically runs $150 to $600 per page depending on research depth. Photography, illustration, and video sit on top. When a proposal looks suspiciously cheap, this is usually the missing line. Someone still has to write the words, and if that someone is your marketing manager, the cost is their time.
Around 5 to 12% on a rebuild, and money you will regret saving: pre-migration crawl and baseline, redirect map, preservation of on-page elements and structured data, XML sitemap configuration, post-launch monitoring. On a site with real organic traffic, this is cheap against the revenue a botched migration risks. It also feeds your visibility in AI-driven search results.
Typically 5 to 10%: cross-browser and cross-device testing, functional and performance testing, and accessibility review against WCAG. Accessibility is increasingly a legal requirement, and remediating a finished site costs several times what building it correctly does.
The recurring line everyone forgets during the project and discovers on first renewal: hosting, CDN, platform licenses, premium plugins, form and email services, security and backup tooling, analytics. Budget for it annually from day one.
Plan on 15 to 20% of build cost per year: security and plugin updates, backups, uptime monitoring, small content changes, bug fixes. A site left unmaintained for eighteen months becomes a security liability and eventually a rebuild. Our overview of website maintenance services covers a sensible ongoing scope.
Five failures I see most often. Each is cheap to prevent and expensive to correct.
You quote 40 pages. Halfway through the build, you discover those 40 pages need 16 distinct layouts, because the team page, leadership page, and careers page are all structurally different.
The estimate used the wrong unit. There is no recovery inside the original budget, only an uncomfortable conversation or absorbed losses.
Never quote before the sitemap is collapsed into a template list. If a client needs a ballpark sooner, give a range with a written assumption about template count.
SEO gets involved eight days before launch and finds that URLs changed without a redirect map, title tags were auto-generated, and structured data was dropped in the rebuild.
Traffic can fall sharply within days, and recovery is measured in months. Meanwhile, the new site, which cost more than the old one, produces less.
Bring SEO into Stage 2. The redirect map is a deliverable with a due date in week six, not something remembered during launch prep.
Every estimate gets a quiet 20% cushion. The timeline looks comfortable. By week eight you are behind anyway, and nobody can explain where the slack went.
Distributed padding is invisible and therefore unmanageable. Work expands to fill it, and you reach the final stretch with no reserve and no data on what consumed it.
Estimate honestly per task, hold one project-level buffer of 15 to 20%, release it deliberately, and report the remaining balance in your weekly recap.
Design gets an enthusiastic but conditional response. Development begins. The "one small thing" turns out to need a layout change, which cascades into three templates already built.
Conditional approval feels collaborative and functions as a trap. Both sides believe a gate has closed. Only one of them is right.
Define approval as a specific action: a signed document, a form submission, or a reply containing an agreed phrase. Anything with an outstanding request is feedback, and it goes back into the current revision round.
Launch happens, the team disperses, and nobody is watching. Two weeks later, someone notices the contact form stopped routing to sales, or that a template shipped with a noindex tag.
Post-launch issues compound silently. Lost form submissions never announce themselves, and by the time anyone notices, the leads are gone.
Include a 90-day post-launch phase with named owners, a monitoring schedule, and a measurement checkpoint against the Stage 1 baseline. Budget it, resource it, and treat day 90 as the real end date.
Three ideas carry most of the value above.
First, plan in templates and systems, not in pages and screens. It changes your estimates, your design process, your build sequence, and your maintenance cost, all at once, and it is the closest thing to a free upgrade in this discipline.
Second, put content and technical SEO on the critical path from week one. Both are routinely treated as things that happen near the end, and both are routinely the reason projects run late or launch into a traffic decline. Content gates design. Redirects protect the equity you already paid for. Neither one belongs in launch week.
Third, decide who decides. Most delays are approval delays. A named approver, a written feedback window, and a decision log will do more for your timeline than any project management tool you could buy.
A good project plan for website development is not something you write once and file. It is a shared reference updated as reality arrives, which it always does. Teams that ship on time are not the ones with perfect forecasts. They are the ones who notice a variance in week three instead of week nine, and who already agreed on what happens next.
If you are planning a website build and want a second pair of eyes on your scope, timeline, or migration approach before you commit, get in touch with the team at ViralChilly. We plan and deliver these projects for agencies and businesses every week, and we are happy to talk through yours. And if you have a hard-won planning lesson of your own, I would like to hear it.
