Few website projects fail in one dramatic moment. They drift. The launch date slides by a month, then another. The budget grows through small “while we’re at it” requests. And when the site finally goes live, it brings in no more enquiries than the one it replaced. Look closely at why website projects fail and the cause is rarely the code or the design. It is usually a decision made badly, or never made at all.
Those decisions can be checked before they cost anything. Below are seven causes that come up again and again, each with its warning sign and prevention, then how to rescue a stalled project and a pre-mortem checklist to run before you sign.
The short answer
Website projects usually fail for organisational reasons, not technical ones. The most common causes are:
- No agreed goal, so nobody can judge whether a design or feature is right.
- Too many decision-makers, so feedback conflicts and approvals stall.
- Choosing a provider on price alone, so essential work is missing from the scope.
- Content left until last, so the build stalls waiting for words and photos.
- Scope creep, where unplanned additions push out time and cost.
- No plan for SEO and redirects in a redesign, so search traffic can fall after launch.
- Nobody owning the site after launch, so it starts to decay on day one.
Each one shows early warning signs while it is still cheap to fix.
What “failed” actually means
Failure takes four forms, and a site can launch on time and on budget yet still fail.
| Type of failure | What it looks like | Usually traced back to |
|---|---|---|
| Late | The launch date keeps moving and momentum fades | Content, approvals, scope creep |
| Over budget | Change requests and extra rounds far exceed the quote | A vague scope, a quote chosen on price |
| Launched without results | It looks better, but enquiries and search traffic stay flat or fall | No goal, no tracking, lost rankings |
| Decays after launch | Stale content, broken forms and security warnings months later | Nobody owns the site |
A good website is strategy, content, design, development, SEO and ongoing care working together. Projects go wrong when one of those becomes someone else’s problem.
Why website projects fail before they start
Three of the seven causes are set up before anyone opens a design file. They are also the cheapest to fix.
1. Nobody agreed what the site is for
The brief asks for something “modern, clean and professional” but says nothing about who the site serves or what those visitors should do. Without a goal, every design review becomes a matter of taste, and there is no basis for turning down a feature.
Warning sign. Ask three people involved what the new site must achieve. Three different answers, or answers about appearance rather than outcomes, mean the goal isn’t agreed.
Prevention. Before you ask for quotes, write one page covering the site’s role, the priority audiences, the two or three actions that matter most (an enquiry, a booking, a download) and how you will judge success. Our website strategy guide walks through those decisions. Then record a baseline for the website KPIs worth measuring, so you can compare after launch.
2. Too many people can say no
A website touches sales, marketing, operations, leadership and sometimes legal, so everyone has a view. When everyone also has a veto, feedback contradicts itself and rounds multiply. The most expensive version is the late arrival: a senior person who skipped the kick-off sees the designs near the end and sends the project back to the start.
Warning sign. Feedback arrives from people who weren’t at the kick-off, or two sets of comments ask for opposite changes and nobody can settle it.
Prevention. Name one decision-maker with the authority to settle disagreements. Everyone else is consulted at fixed points, with comments merged into one list before they reach the designer. Involve senior stakeholders when the goals are agreed, not when the designs are.
3. The provider was chosen on price alone
Two quotes for what looks like the same website can differ several times over, because they describe different projects. The low one often assumes you supply every word and photo, allows one round of changes, and says nothing about redirects, training or tracking. That work doesn’t disappear. It returns as change requests, or quietly never happens.
Warning sign. You are comparing proposals by the total at the bottom, and none says who writes the content, how many revision rounds are included or what happens to your old page addresses.
Prevention. Compare scope, not totals. Send every provider the same written website brief, ask each the same questions before you hire a web designer, and insist on a fixed price with the pages, features and languages listed.
Why they go wrong during the build
Once work starts, the two biggest risks are the content nobody is writing and the feature list that keeps growing.
4. Content left until last
Design is visible and exciting. Content is slow and belongs to busy people. So designs are approved with placeholder text, the build goes ahead, and then everything stops while the project waits for service descriptions, prices, photos and translations. When the real words arrive, they don’t fit the layouts, and approved templates have to change.
Warning sign. Designs are signed off with placeholder copy, or “we’ll send the text next week” has been said more than twice.
Prevention. Treat content as a workstream, with a website content plan that gives every page a writer, an approver and a deadline set backwards from launch. Request the slow material first (photography, permission to name clients, legal text), design the key templates with real content, and give every language its own native reviewer and time.
5. Website scope creep
Scope creep is the gradual growth of a project beyond what was agreed: an extra section here, a booking system there, a second language someone assumed was included. Each request seems small. Together they push out the launch and the budget, and because nothing was formally changed, who pays is argued at the end.
Warning sign. New requests are agreed in meetings or chat messages, and nobody records what they do to the timeline or the cost.
Prevention. Agree a change process at kick-off. Write down every new request with its effect on cost and timeline, then:
- Swap it for something of similar size already in scope,
- Approve it with a new price and date, in writing, or
- Park it on a list for after launch.
Parking is underused: a site that launches with the essentials and improves in phases beats one that never launches. A website project plan with clear sign-off points helps.
Why they fail at launch and after
The last two causes don’t delay the launch. They undo its results.
6. No plan for SEO and redirects in a redesign
A redesign that changes page addresses without redirecting them can throw away years of search visibility: visitors arriving from Google, bookmarks and links on other sites land on error pages, and rankings can drop soon after launch. Two other launch mistakes are common: rewriting well-ranked pages without regard for the searches that found them, and launching with the staging site’s “hide from search engines” setting still switched on.
Warning sign. Nobody has listed your current URLs, or the answer to “what happens to our Google rankings?” is “we’ll look at SEO after launch”.
Prevention. Before the build, list every current URL (from a crawl, your XML sitemap, your analytics and Search Console’s Performance report), map each to its new address and prepare permanent (301) redirects for launch day. Keep what already ranks unless there is a reason to change it, check indexing settings at launch and watch Search Console afterwards. Then leave the redirects in place: Google’s site-move guidance says to keep them for as long as possible, generally at least a year. The website migration SEO checklist covers every step.
7. Nobody owns the site after launch
Many project plans end on launch day. The provider hands over, the internal team returns to their day jobs, and nobody keeps the site current and secure. Months later the prices are out of date, a plugin update has broken the contact form, and nobody has noticed.
Warning sign. The plan has no named owner after launch, no maintenance budget and no training for editors. Or the domain and hosting logins sit with the provider rather than with you.
Prevention. Name the owner before launch and give them a routine: who updates content, who checks enquiries and analytics monthly, who handles updates and backups. Train your editors, and put the domain, hosting and admin accounts in your organisation’s name. If the technical side is beyond your team’s time or skills, a website care plan covers updates, backups, security and monitoring.
How to rescue a project that has stalled
If you are reading this mid-project, the way out is usually to shrink the problem, not to push harder.
- Take stock in writing. List what is approved, built and waiting, and on whom. Usually one or two blockers are holding everything up.
- Re-confirm the goal. Anything that doesn’t serve the two or three key actions is a candidate for later.
- Define a launchable version: the smallest set of pages and features that clearly beats the current site. Move everything else to a phase-two list.
- Name one decision-maker if there isn’t one, and agree a turnaround time for feedback.
- Replan with dates on both sides. Your content and approvals need deadlines too.
- Secure your access. If the relationship with your provider has broken down, first confirm you control the domain, hosting, files and database.
Meanwhile, fixing the old site’s worst problems, such as a broken form, takes pressure off the new launch date.
A pre-mortem checklist to run before you sign
A pre-mortem is a planning technique described by the psychologist Gary Klein in Harvard Business Review in 2007. Before work starts, the team imagines the project has already failed (for a website, picture a year after launch) and each person writes down, on their own, every reason why. It gives people permission to voice doubts nobody wants to raise at an optimistic kick-off.
Run one, then check your plans against this list. Every unticked box is a website project risk to deal with now.
Goals and decisions
Scope and content
Launch and after
What to do next
Most website project mistakes show before a contract is signed: in a vague brief, a quote without a clear scope, a content plan that doesn’t exist yet. That is also when they cost least to fix, so an hour on the pre-mortem is well spent.
If you are replacing an existing site, our website redesign work is built around these risks: an audit before any design, a fixed price in writing, every old URL redirected and editors trained to run the site. Our guide to the website redesign process shows how the stages fit together. And for a baseline first, a free website audit shows where your current site stands, so you know what the new one has to beat.