Most owners ask how long it takes to build a website at the same moment they ask what it costs, and the two answers are tied together. The honest version: a small brochure site can go live in a few weeks, a proper business site usually takes a couple of months, and anything with logins, payments or integrations takes longer. What decides where you land is rarely the code. It is decisions, content and the slow parts nobody puts on the schedule, like domain access and Google noticing the site exists.
I build sites through Pinn.Media and work as Solutions Architect at Lonestar Home Healthcare, so I see timelines from both sides: the builder trying to ship and the business trying to get approvals out of busy people. This post breaks the schedule into phases, shows where the weeks actually go, and gives you a checklist that shortens yours.
How long it takes to build a website, by type
These are the planning ranges I use when I scope a project, assuming the client answers questions within a couple of days and the content is ready when it is needed. They are my estimates, not industry statistics and not a quote.
| Type of site | What it usually includes | My typical planning range |
|---|---|---|
| Brochure site | 1 to 6 pages, contact form, analytics | About 2 to 4 weeks |
| Business site | 10 to 20 pages, a CMS, service and location pages, custom design | About 6 to 10 weeks |
| Redesign or platform migration | Everything above, plus redirects and protecting existing rankings | About 8 to 12 weeks |
| Site with a tool or integration | A calculator, booking flow, CRM or ERP connection | About 10 to 16 weeks, depending on the other system |
| Custom web app or portal | Accounts, dashboards, roles, data that changes | Months, planned in phases |
If you have read my breakdown of what a website costs in Dallas, the shape will look familiar. Scope drives both numbers, and every row above the first one has a step change in decisions, not just pages.
Where the weeks actually go
A website schedule has six phases. The build itself is often the shortest of the heavy ones.
1. Discovery and scope
Who is the site for, what should a visitor do, which pages exist, what does the site connect to? I want a written page list and a single decision maker before design starts. On a brochure site this is a meeting and a document. On a site with integrations it can take a few weeks, because someone has to find out what the other system can actually do.
2. Content
Copy, photos, team bios, service descriptions, testimonials you have permission to use. This is the phase that most often doubles a timeline. A designer can lay out a page in a day, but a services page waiting on three people to agree on wording can sit for a month. If you only remember one thing from this post: start writing before the project starts.
3. Design
Usually a homepage direction first, then one or two key inner page templates, then the rest follows the system. Each round of feedback costs days, mostly in waiting. Two rounds is healthy. Five rounds usually means the brief or the decision maker was not settled in phase one.
4. Build
Turning designs into a working, responsive site with a CMS you can edit. For a business site, this is often a few focused weeks. It stretches when there is something custom inside: when I built the OSCPA fee estimator, the logic of which tax forms map to which price had to be agreed with the firm before any screen could be finished. On PrintVision, the Next.js site was wired into the client’s own ERP, which meant the schedule depended on how that system exposed its data, not only on my side.
5. Testing and review
Phones, browsers, forms, speed and accessibility. I check pages against Google’s Core Web Vitals targets, which web.dev defines as a Largest Contentful Paint within 2.5 seconds, an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads. For accessibility I review against WCAG 2.2, the current W3C Recommendation, which defines three conformance levels: A, AA and AAA. Finding problems here is cheap. Finding them after launch is not.
6. Launch
Pointing the domain, setting up redirects, submitting a sitemap and making sure forms deliver to the right inbox. The launch day itself is short if everything before it was done. It is long if nobody knows who has the login for the domain registrar.
The waits that are outside anyone’s control
Some delays are set by other companies’ rules. Build them into the plan instead of being surprised by them.
- Domain transfers: ICANN’s guidance for domain holders says a registrar may deny a transfer within 60 days of initial registration, or within 60 days of the last transfer to a different registrar. If you just bought a domain and want to move it to another registrar before launch, you may not be able to. Point its DNS instead and move it later.
- Google finding the site: Google’s own getting-started guide says it can take a few weeks for Google to notice a new site, or changes to an existing one. Its recrawl documentation adds that crawling can take anywhere from a few days to a few weeks, and that requesting a recrawl of the same URL repeatedly won’t make it faster.
- Google Business Profile: if your project includes setting up or reverifying your profile, Google says that after you complete the verification steps you may wait up to 5 business days to be verified while it reviews your info, and that most postcard codes arrive within 14 days.
- Speed data after fixes: the Search Console Core Web Vitals report works from a 28-day window, and its validation tracking runs a 28-day monitoring session. Performance work you do at launch takes about a month to show up there as passed.
None of these stop you launching. They change what “done” means. The site can be live on day one and still be weeks away from showing up properly in search, so don’t schedule a big marketing push for the morning after launch.
What makes a website take longer
In my experience, these are the causes of slipped timelines, roughly in order of how often I see them:
- Content not ready. The site waits on copy, photos or approvals.
- More than one decision maker. Feedback arrives in contradicting pieces from different people.
- Scope that grows mid-build. “While you’re in there” turns a brochure site into a portal.
- Integrations with unclear access. Nobody has API credentials, or the other vendor is slow to respond.
- Migration without an inventory. Redirects get planned at the end instead of the start. I cover the right order in migrating WordPress to Next.js without losing SEO.
- Regulated content. In healthcare, forms and chat tools need a privacy review before they go live, and that review has its own queue.
How to shorten the timeline without cutting quality
Here is the checklist I send clients before kickoff. Each item removes a wait from the schedule.
- Name one person who approves design and copy, and tell everyone else to send feedback through them.
- Gather logins before kickoff: domain registrar, DNS, current hosting, Google Search Console, Google Business Profile, analytics, and any CRM or booking tool the site connects to.
- Write a page list with one sentence per page saying what it is for.
- Draft the copy for your three most important pages, even roughly. Editing is faster than writing from nothing.
- Collect real photos of your team and work. Stock imagery can fill gaps, but sourcing it is its own delay.
- Decide what the forms do: who receives them, what fields you need, and where the data goes next.
- Agree on a launch scope and a phase two list. Anything that is not essential for launch goes on the list, not into the build.
- Book review time on your calendar for each design and content round, so feedback comes back in days, not weeks.
Launch smaller, then add
The biggest timeline lever is phasing. A business site with your core service pages, a clear contact path and solid technical foundations can go live while the blog, the calculator or the client portal is built behind it. You start collecting leads and search history sooner, and the second phase is shaped by what real visitors do instead of guesses.
When a fast timeline is the wrong goal
Speed is not always the right priority. I would push back on a rushed schedule when:
- You are migrating a site that already ranks. Rushing redirects is how businesses lose traffic they spent years earning.
- The site collects sensitive information. Intake forms for a healthcare agency or a tax firm need the right vendors and settings in place before launch, not after.
- Your positioning isn’t settled. If you are still deciding what you sell or who for, building pages first means rewriting them later. Sort out the message, then build.
- The brand is changing too. A rebrand and a site at the same time is common and works well, but the identity has to lead by a few weeks so the site isn’t designed around a logo that changes.
The other direction matters too. If what you need is a credible page so people can find your phone number, a template on a website builder this week beats a custom site in two months. Not every business needs a build.
A sample schedule for a business site
For a roughly fifteen-page service business site with a CMS and no complex integrations, a schedule I would consider realistic looks like this:
- Week 1: discovery call, page list, access collected, content plan agreed.
- Weeks 2 to 3: homepage design direction and first feedback round; client drafts copy in parallel.
- Weeks 3 to 4: inner page templates designed; copy edited and approved.
- Weeks 4 to 7: build, CMS setup, forms, redirects mapped if there is an old site.
- Week 8: testing on phones and browsers, speed and accessibility checks, final content review.
- Launch week: DNS change, sitemap submitted in Search Console, forms tested live, analytics checked.
- The month after: watch Search Console for errors and fix what real usage reveals.
Notice how much of this runs in parallel. The schedules that hit their dates are the ones where content work starts on day one instead of after design is approved.
Frequently asked questions
How long does it take to build a website for a small business?
A simple brochure site can usually be ready in a few weeks, and a standard multi-page business site in about two months, if content and feedback arrive on time. Integrations, migrations and custom tools add time. Ask any builder for a phase-by-phase schedule, not just an end date.
Can a website be built in a week?
A one-page site or a template on a website builder can, if the copy and photos already exist. A custom-designed multi-page site in a week usually means skipping discovery, review or testing, and those skipped steps tend to come back as fixes after launch.
How long after launch will my site show up on Google?
Google says it can take a few weeks to notice a new site, and that crawling can take a few days to a few weeks. Google says a sitemap helps search engines discover URLs but doesn’t guarantee they will be crawled and indexed, and repeated recrawl requests for the same URL won’t speed it up. Ranking well for competitive searches takes longer than being indexed.
What is the most common reason website projects run late?
In my projects, it is content and approvals, not development. Copy that isn’t written, photos that don’t exist yet and feedback from several people at once account for more lost weeks than any technical problem.
Is a redesign faster than a new site?
Not usually. A redesign has everything a new site has, plus an inventory of existing pages, redirects and checks that rankings carry over. The content may already exist, which helps, but it often needs rewriting anyway.
Planning a site and want a real schedule?
If you tell me what the site needs to do and what you already have, I can give you a phase-by-phase timeline and flag the waits before they happen. You can see what I build on the services page, or get in touch and we’ll map it out.
