Website project checklist: what has to be settled first

The short answer

Before a website project starts, five things have to be settled: goal and target group, who supplies copy and images, who decides, budget and time frame. In a relaunch, the list of all old URLs comes on top. If one of these points is missing, the project almost always gets delayed in our experience. The technology is rarely the problem.

This checklist is split into four phases: before the kickoff, during implementation, just before go-live and the first two weeks after. It applies to a new build just as much as to a relaunch. Points that only count in a relaunch are marked.

What has to be settled before the kickoff?

These points belong before the first design meeting. Anything settled later costs rework.

• Goal and target group in one sentence. Not "look more modern", but concrete: who should the site convince, and of what? Without this sentence every design discussion becomes arbitrary.
• A measurable goal. For example: more enquiries via the form, more calls, more bookings. Decide how you'll recognise success in three months.
• Relaunch only: a list of all existing URLs. Ideally as an export of the sitemap or from a crawl tool. It's the basis for the redirects, so rankings survive the move.
• Content responsibility. Who writes the copy, who supplies images, by when? Without clear responsibility every project stalls here.
• CMS requirements. Who should change what themselves after launch? How much training is planned for that?
• One person who decides. On the client side you need someone with decision-making authority. Otherwise feedback rounds get stuck in internal loops.
• Budget and time frame. An honest frame from the start prevents later disputes about scope and deadlines. Our article on the price range for websites gives orientation.
• Access. Domain, hosting, DNS, Google Search Console, analytics and Google Business Profile. Clarify early who has which login.

What belongs in a good briefing?

A briefing doesn't have to be long. One page is enough if it answers these questions:

1. What do you offer, and what sets you apart from the competition?
2. Who are your best customers, and which questions do they ask before buying?
3. What should a visitor do on the website: call, enquire, book or buy?
4. Which three websites do you like, and why exactly?
5. What bothers you most about your current site?
6. Which content, photos and logos already exist?
7. By when should the site be live, and is there a fixed occasion?

With these answers the project starts much faster. The rest gets settled in the kickoff.

Which legal points belong on the list?

Legal matters are often only considered shortly before launch. Then there's no time for clean solutions. That's why these points belong in the concept already. They refer to German law, where we work. Important: this is a checklist, not legal advice.

• Legal notice (Impressum). Under § 5 DDG, commercial digital services need an easily accessible legal notice [1].
• Privacy policy. It has to match the services actually used, such as forms, analytics or maps.
• Consent for cookies and tracking. For cookies and similar technologies that aren't strictly necessary, § 25 TDDDG generally requires consent [2]. So plan the cookie banner in.
• Accessibility. Since 28 June 2025 the German Accessibility Strengthening Act (BFSG) has applied to certain online offers for consumers, such as online shops [3]. Micro-enterprises that offer services are exempt. But easily readable contrast and clean structure pay off for every website.
• Image and font rights. For every photo and every font it has to be clear whether you may use it.

What matters during implementation?

• Start content early. Copy and images are created in parallel with the design, not afterwards. Otherwise the end of the project becomes a bottleneck.
• Relaunch only: plan redirects. Every old URL gets a documented target on the new site. Google advises redirecting old URLs to matching new pages. Sending many old URLs to the homepage across the board can be treated as a soft 404 [4].
• Use a staging environment. The new site is built in a non-public staging environment. It's checked there and never rebuilt directly on the live site.
• Protect staging from Google. Password protection stops Google from finding half-finished pages.
• Feedback in fixed rounds. Collected feedback instead of a running stream of individual comments keeps the schedule.
• Test on real devices early. Not just at the end, but after every major design step. Especially on a phone.

What do you check just before go-live?

• Relaunch only: all redirects are tested. Google recommends permanent redirects (301 or 308) [4].
• No "noindex" and no password protection from staging has been left on the live site.
• Search Console is verified, the new sitemap is submitted.
• Analytics is measuring, and the cookie banner controls measurement correctly.
• Titles, descriptions and structured data are checked on all pages.
• Load time and Core Web Vitals are tested on a real phone, not only in the browser simulator [5].
• A 404 page exists and leads back to the homepage.
• Every form has been run through once completely, including the confirmation email.
• SSL certificate and domain settings are checked, the site runs under one address only.
• A backup of the old site is saved before it's replaced.

What happens in the first two weeks after launch?

The launch isn't the end of the project. It's the start of the observation phase.

• Watch rankings. Fluctuations after a relaunch are normal. Google itself expects temporary fluctuations during a move [4]. For medium-sized websites it can take a few weeks until the new URLs appear. A lasting drop for important search terms, on the other hand, is an alarm signal.
• Check error pages in Search Console. Overlooked redirects show up here reliably.
• Evaluate the first user data. Where do visitors drop off? Does the path to the enquiry work as planned?
• Evaluate real enquiries. Did they come via the new buttons or still via detours?
• Keep the redirects. Google recommends keeping them as long as possible, generally at least a year [4].

Which mistakes happen most often at launch?

Most go-live mishaps aren't technical riddles. They're forgotten details. These are the ones we see most often in our project experience:

• The site stays invisible. A "noindex" from staging moves over to the live site. Google may then index nothing, and nobody notices for weeks.
• The form sends into the void. The recipient address is still from the test phase, or emails land in spam. A test send on launch day prevents this.
• Redirects are missing for subpages. The homepage is redirected, but old blog articles and PDFs aren't. These are exactly the pages that often have links from outside.
• Measurement is missing. Analytics or Search Console aren't connected. Then the figures for comparison with the old site are missing later. What you should measure after launch for Google, Maps and AI search is in our overview SEO & GEO.
• Two addresses for the same site. The site can be reached with and without "www", without a redirect. Pick one address and redirect the other.
• Launch on a Friday afternoon. If something gets stuck afterwards, nobody is reachable. Plan the go-live for a weekday morning.

Who does what?

Most delays happen at handovers. This split has proven itself in our projects. Adapt it to your team:

Task	Client	Agency
Goal, target group, budget	Decides	Asks questions, sharpens
Content and facts	Supplies knowledge, photos, approvals	Writes and structures
Design	Gives collected feedback	Designs and implements
Access (domain, hosting, accounts)	Provides it, stays the owner	Sets it up
Legal texts	Responsible, with a lawyer if needed	Builds them in technically
Redirects and launch	Approves	Plans, tests, goes live

How long does a website project take?

With us, an SME website with 5–12 pages and no shop is live in 4 weeks, counted from the completed briefing. A shop or several languages take longer.

That only works if the points from phase 1 are settled. Working through them in the right phase often saves several weeks in our experience. And the project stays relaxed for everyone involved. How you can tell your current site needs an update is in the 7 signs.