The short version: a website rarely slips because one big thing failed. It usually slips because five small things were not written down early enough.
When a business asks for a new site, I hear the same questions in different outfits. How long will this take? What do you need from us? When does design end and hosting begin? What happens to SEO, forms, and training? And the one everybody saves for the end: what could possibly delay launch?
Those questions matter because a website project is not only a design exercise. It is a sequence of handoffs. Google’s Search Console setup guide and sitemap guidance are useful reminders that launch readiness includes search visibility, while Let’s Encrypt’s getting-started page shows how early certificate setup matters when HTTPS is part of the plan. In other words, a site can look finished and still not be ready to go live.
In this guide, I am going to map the real delivery path: what each phase includes, how long a typical project takes by size, what clients need to supply, where delays usually happen, and what launch day actually looks like when it goes well. If you want a broader sense of how these pieces fit into the rest of the site, the homepage, web design services, hosting and domain information, and references pages are useful context.
Here is the plain version: if everyone knows what happens in each phase, the project feels calmer. If nobody knows, the same project starts behaving like a calendar that was left in the rain.
What a Website Delivery Timeline Actually Includes
A delivery timeline is the schedule for getting a website from first inquiry to public launch. It usually includes discovery, content planning, design, development, testing, hosting or domain setup, SEO basics, launch, and training. It does not mean every possible marketing task, every future feature request, or a promise that the site will rank for everything by Friday.
I like to define the timeline this way because it keeps expectations honest. Design is one stream. Content is another. Hosting and domain access are another. Search setup, measurement, and handover are also separate streams. They meet at launch, but they do not move at the same speed.
That separation matters. If a business expects copy approval, new photography, domain transfer, and staff training to happen after design is already “done,” the calendar will stretch whether anyone wants it to or not. The project is not failing in that case. It is simply revealing that the work was always bigger than the first estimate.
What it does include
- Project discovery and scope
- Page list, goals, and content plan
- Visual design and content layout
- Build, QA, and mobile checks
- Hosting, domain, email, and SEO setup
- Launch, handover, and first-week support
What it usually does not include
- Unlimited revisions with no approval deadline
- Full copywriting for every page unless it was scoped that way
- Ongoing ad management or monthly SEO retainers
- New feature requests that arrive after sign-off
- Guaranteed search rankings or fixed lead volume
That last point is important: a launch timeline can describe work, approvals, and technical readiness. It cannot honestly promise market results that depend on competition, budget, content quality, and search engine behavior.
The 5 Phases of Delivery
Most website projects become easier to understand when they are broken into five phases. I use this quick map when I explain the process to clients because it turns a vague “when will it be ready?” question into smaller decisions.
| Phase | Main purpose | Typical outcome |
|---|---|---|
| 1. Discovery & scope | Agree on pages, goals, audience, and constraints | A clear brief and timeline |
| 2. Design & content layout | Plan page structure and visual direction | Approved layouts or wireframes |
| 3. Build & QA | Turn the approved design into a working site and test it | A staged site that behaves correctly |
| 4. Hosting, domain & SEO setup | Prepare the technical pieces that make the site live and findable | DNS, SSL, analytics, and SEO basics in place |
| 5. Launch & training | Switch live, verify everything, and hand the keys over | Public site plus client training and support notes |
1. Discovery & Scope
This is where the project stops being a nice idea and starts becoming a plan. The goals are simple: decide what the site needs to do, what pages it needs, who will approve the work, and what has to be ready before launch. For a small business, this phase often takes a few days. For a larger site with multiple stakeholders, it can take a week or more.
The discovery phase should answer questions like these:
- What is the main goal: leads, bookings, calls, downloads, or sales?
- Which pages are required on day one?
- Who supplies copy, photos, and approvals?
- What technical access is already available for hosting and the domain?
- Are there existing URLs, email addresses, or SEO assets that must not break?
2. Design & Content Layout
Once scope is clear, design can do real work instead of guessing. This phase is not just “make it pretty.” It is where page structure, content order, call-to-action placement, and mobile behavior get decided. A homepage that needs to persuade visitors is not the same as a contact page that just needs to remove friction.
For example, a service business might need a hero section, a short proof section, service blocks, references, and a clear contact prompt. A portfolio or reference page may need a different rhythm: visual proof first, explanation second, and call-to-action after the reader understands what they are seeing.
That is why I prefer to approve layout before build. It is much cheaper to move a section on a wireframe than to move a section after three pages of content have already been written around it.
3. Build & QA
Build is where the approved design becomes an actual website. The work includes responsive layout, forms, menus, template behavior, page loading, and browser checks. QA is the quiet part that saves the loud part later.
At this stage, I am looking for issues like:
- Broken links or missing pages
- Form fields that do not send properly
- Mobile layouts that collapse awkwardly
- Images that are too heavy or cropped badly
- Hidden text, duplicate headings, or inconsistent buttons
This is also where a realistic launch timeline starts to show its edges. If the build is waiting on one piece of content, the QA phase may be paused by a detail that sounds small but is actually critical. “We just need the final phone number” sounds tiny until you are testing contact forms across three templates.
4. Hosting, Domain & SEO Setup
This is the phase that often gets squeezed into the last minute, which is exactly why it deserves its own slot. The live site needs a home, a domain route, a certificate, basic analytics, and indexable pages. If any of those are missing, the site may launch in name only.
The technical checklist usually includes:
- Domain access and renewal confirmation
- DNS records and nameserver checks
- SSL certificate setup for HTTPS
- Analytics or tag manager installation
- Search Console verification and sitemap submission
- Basic on-page SEO checks for titles, descriptions, and headings
If the site sends lead forms or campaign traffic, this is also where the connection to online advertising support starts to matter. Traffic is only useful if the landing page loads correctly, the form works, and the conversion is measured.
5. Launch & Training
Launch is the handoff from “building” to “running.” The site goes live, the final tests are repeated on the public domain, and the client receives the practical parts: how to edit content, where forms go, what to watch in the first week, and how to request changes without guessing the process.
Training should be short, useful, and concrete. Nobody needs a ceremonial lecture. People need to know how to update a headline, replace an image, check a form, and decide who to call if something breaks. That is what makes the launch feel usable instead of fragile.
Typical Time Ranges by Project Size
No two projects are identical, but most small-business sites fall into three rough sizes. These ranges assume normal responsiveness, not a universe where every approval arrives instantly and every copy draft is perfect on the first try.
| Project size | Typical scope | Realistic timeline |
|---|---|---|
| Starter | Home, 2 to 4 supporting pages, one contact form, existing logo and content | 1 to 2 weeks |
| Business | Home, services, references, contact page, SEO setup, some content writing or rewrites | 3 to 5 weeks |
| Multi-page | 8 to 15+ pages, multiple forms, content revisions, redirects, and fuller handover | 6 to 10 weeks |
Here is the plain version of those numbers.
Starter project example: a small service business has a logo, short copy, and a simple contact form ready to go. The structure is straightforward, the approvals are fast, and the site can move from discovery to launch in a couple of weeks.
Business project example: a consulting firm needs stronger service pages, a references section, basic SEO, and a more careful review cycle. That usually pushes the project into the three-to-five-week range because content and approvals matter as much as design.
Multi-page project example: a larger organization wants several page templates, internal links, redirects, multiple stakeholders, and a training session after launch. That is a real project with real coordination, so it usually needs six weeks or more even when nobody is dragging their feet.
The main variable is not the number of pixels. It is the number of decisions.
Dependency Checklist: What the Client Must Confirm
A project can only move as fast as its slowest dependency. That is not a design opinion. It is just how handoffs work. If I want a timeline that holds together, I ask the client to confirm the following early:
| Dependency | What to provide | Why it matters |
|---|---|---|
| Logo and brand assets | Logo files, colors, fonts, imagery style, and any brand guide | Design needs usable source files, not screenshots of a screenshot |
| Copy | Page text, service descriptions, calls to action, and legal copy | Layout can only be finalized when the content exists |
| Photos or screenshots | Team photos, project images, product shots, or approved stock choices | Visual proof makes service pages and reference pages feel real |
| Domain access | Registrar login, renewal status, and DNS control | Nothing goes live without the ability to point the domain correctly |
| Hosting access | Panel login, server access, backups, and environment details | The build needs somewhere stable to live and be tested |
| Email setup | Which inboxes should exist, who receives form mail, and who replies | Launches often fail in the inbox before they fail in the browser |
| Preferred pages | Home, service pages, references, contact, blog, and any extras | Prevents scope drift and “we forgot that page” surprises |
| Approval owner | One person or one decision path for feedback consolidation | Too many approvers can turn a simple site into a committee sport |
The most useful client habit is not speed. It is completeness. A complete package of assets and decisions saves more time than fast but partial replies.
Where Timelines Usually Slip
Most delays are predictable once you know what to look for. The project does not usually fall apart because of a major technical crisis. It usually drifts because one dependency keeps waiting on another dependency.
- Late copy: design finishes, but pages cannot be finalized because the text is still in draft.
- Unclear approvals: one person likes the layout, another wants changes, and nobody is the final yes.
- Domain or hosting access issues: the login is missing, the registrar is locked, or nobody remembers who owns the account.
- Asset delays: logos arrive in the wrong format, photos are not cropped, or screenshots are missing.
- Too many review comments at once: feedback is spread across email, chat, and a screenshot marked “move this a bit.”
- SEO and tracking ignored until the end: analytics, sitemap, and meta details are treated like afterthoughts, then suddenly become launch blockers.
A good timeline does not pretend these problems will never happen. It simply names them early enough to prevent the project from becoming a detective story.
Approval Workflow: How Many Review Rounds to Plan
For most small-business projects, I plan two review rounds. One round is for structure and major direction. The second is for refinement and final checks. That is usually enough when the scope is controlled and the client is responsive.
More than two rounds can be useful for larger projects, but only if the rounds are clearly defined. Otherwise “another round” becomes a polite way of saying the project has started collecting opinions for emotional support.
Review Round 1: Structure
This is where the client looks at page layout, section order, headline direction, and whether the design is pointing at the right business goal. Feedback here should focus on the big picture:
- Does the page tell the right story?
- Is the call to action clear?
- Are the sections in the right order?
- Is anything missing that matters on day one?
Review Round 2: Refinement
This is for final adjustments, not a reopening of the entire project. Good feedback here is concrete:
- Replace image A with image B
- Shorten this heading
- Move the testimonial block above the contact prompt
- Check this phone number and form label
Actionable feedback saves time. “Make it better” is not feedback. “Change the primary CTA on the service page to ‘Request a Quote’ and move it above the references block” is feedback.
Launch Day Checklist: What Gets Tested
Launch day is not a ceremony. It is a checklist with consequences. I prefer to test the things real users will touch first.
| Area | What to test | Why it matters |
|---|---|---|
| Forms | Submission, confirmation, inbox delivery, and spam filtering | Lead capture is usually the first business goal |
| Email links | Mailto links, support addresses, and reply behavior | Visitors should reach the right inbox without friction |
| Tracking | Analytics tags, conversion events, and tag manager triggers | If measurement is broken, you lose the first clean data point |
| Mobile view | Menus, tap targets, image scaling, and sticky elements | Most visitors will not be using a giant desktop monitor |
| Navigation | Menu links, footer links, and internal page flow | Broken paths make a polished site feel unfinished immediately |
| SEO basics | Titles, meta descriptions, sitemap, and canonical checks | The site should be ready to be found, not just seen |
| Security basics | HTTPS, plugin or app access, backup state, and admin roles | Launch is the wrong time to discover a weak access setup |
For search-related verification, Google’s Search Essentials is a solid reference for the “does this site make sense to search engines?” question. If a site is going live with email forms, DMARC’s overview is helpful for understanding why mail authentication belongs in the launch checklist instead of in a future cleanup project.
Handover & First-Week Support
Go-live is not the end of the project. It is the handover from the build team to the running site. The first week is usually for monitoring, small fixes, and making sure the real-world version behaves like the tested version.
Good first-week support usually includes:
- Quick checks on forms, links, and analytics
- Minor content corrections that show up after launch
- Fixes for unexpected mobile quirks or browser behavior
- Confirmation that contact requests are reaching the right people
- Guidance on how to request changes after the site settles
This support window should be practical, not vague. If the client knows how long the check-in period lasts and how to report an issue, everyone can breathe a little easier. The goal is to stabilize the site, not to keep the whole project in a permanent state of “just one last thing.”
The real handover question is simple: can the client run the site, understand the next steps, and know who to call when something changes?
FAQ: Common Questions About the Launch Process
Can we launch with placeholders?
Sometimes, yes. But only for content that is explicitly non-critical. A temporary team photo or placeholder image may be acceptable during build. A placeholder contact form, missing legal page, or blank service page is a different matter. If the page is meant to generate leads, it should not launch as a nearly finished thought.
What if the domain is not ready?
If the domain is not ready, the site is not ready. You can still finish the design, build, and staging work, but the public launch should wait until the domain, DNS, and SSL path are confirmed. Otherwise you risk a launch that is technically visible to the team but not reliably visible to customers.
Can SEO start before launch?
Yes, and it should. SEO in the launch phase is mostly about clean structure, internal links, page titles, meta descriptions, sitemap readiness, and indexability. That is not the same as long-term optimization, but it gives the site a proper starting position instead of asking search engines to guess what the pages mean.
How many review rounds should we budget for?
Two rounds is the sweet spot for many small projects. One for structure, one for refinement. Larger projects may need more, but more rounds should mean more definition, not more wandering.
What if the content arrives late?
Then the schedule should be revised honestly. You can often continue with approved sections or placeholder text, but the launch date should be based on the actual critical path. A timeline works best when it reflects reality instead of optimism with a nicer font.
A Simple Way to Think About the Whole Timeline
If I had to reduce the whole process to one sentence, I would say this: delivery moves quickly when decisions are made early, content is supplied on time, and technical setup is treated as part of the project, not as a mystery behind the curtain.
The phases are not there to slow the project down. They are there to keep the right work from happening in the wrong order. Discovery keeps scope honest. Design keeps the page structure useful. Build and QA catch the glitches before customers do. Hosting, domain, and SEO setup keep the site reachable and measurable. Training makes sure the site is not just live, but usable.
That is the realistic version of a website timeline. Not magic. Not drift. Just a clear sequence that gives everyone a fair shot at launch.
Key Takeaways
- A delivery timeline is a phase-by-phase plan, not a vague estimate.
- Client inputs matter as much as design work. Copy, logos, approvals, and access can move the schedule.
- Most delays come from missing dependencies, not from one giant failure.
- Two review rounds are enough for many small-business sites.
- Launch day should test forms, links, mobile layout, tracking, and SEO basics.
- First-week support should focus on stabilization, not endless new requests.
If you are planning a new site and want the project to move in a calm, predictable way, the next useful step is to define the page list, asset checklist, and approval owner before design starts. If you want help with that part, the contact page is the right place to start the conversation.