Build your own website: routes, costs, legal basics and SEO 2026

Building your own website is no longer rocket science: domains, hosting and tools are affordable, and there are free helpers for texts, images and technology. What remains are three real decisions: which route fits your project, what it really costs over the years, and what you must sort out legally and technically before launch. That is exactly what this guide covers, step by step with the matching free tools.

Which route suits you: website builder, CMS or coding it yourself

There are three technical base routes. One thing upfront: freelancers and agencies are not a fourth route, they are possible contractors for any of them.

Three common misconceptions belong to this topic: "every feature you want is included in the monthly subscription" is rarely true, so is "free software means a free website", and "static means maintenance-free and unattackable" even more so. With a builder you do not own nothing, by the way: Wix explicitly states that the content remains the user's, even though the site must run on Wix servers.

A practical decision sequence:

1. Note your goal and must-have features: inform, leads, blog, appointments, shop or custom tools.
2. Decide who delivers texts and images and who should later change content without developer help.
3. Test the features you need in the concrete tariff, do not trust the description.
4. Assign technical operation: updates, backups, recovery, form delivery.
5. Record money budget and available own time separately.
6. Only then choose technology and, if applicable, a contractor.

For the self-coded route, the studio-tools text and code tools help: the Markdown to HTML converter turns written content into finished markup, the Slug Generator turns page titles into readable URLs.

What does a website really cost? All costs from domain to maintenance

The honest answer first: there is no universal price list, and the broad cost keywords online are heavily commercial. What you need instead is a complete cost checklist and a few directly verified price anchors.

Directly verified price anchors (as of: 23.10.2026):

Two traps hide in such numbers. First, promotional prices are not regular prices: the IONOS Plus tariff costs 1 euro for twelve months and then 11 euros per month. Always calculate with the regular price after the promotion. Second, "free" is rarely free: at Vercel the hobby tier is explicitly limited to non-commercial use, company advertising and AdSense can count as commercial use there.

The complete cost checklist across the lifecycle, as check items before a booking or a request for quotes:

One point almost all cost guides omit: for commissioned design-oriented web design, the German artists' social security levy (Künstlersozialabgabe) can apply. It is 4.9 percent in 2026 and is paid by the client when the obligation applies, for example from a commission threshold of 1,000 euros for the named groups. At 6,000 euros of liable remuneration that is arithmetically 294 euros extra. Whether it applies in an individual case depends on the type of service; pure technical setup is assessed differently from design work.

Example calculations for the first year (own model calculation from the verified tariffs, excluding own time and extras):

Add the rule of thumb for own time: 40 hours of work at a personal time value of 30 euros turn an 87-euro hosting year into an economic project of roughly 1,350 euros. That is not a scare tactic but the most honest number in the whole comparison, because own time is the biggest item when building yourself. To see running costs after launch in the context of the overall budget, the household budget calculator helps you view website costs alongside your other fixed costs.

Legal before launch: imprint, privacy, cookie banners and accessibility

This section provides orientation, it is not legal advice. The order is deliberate: first provider identification and data flows, then the banner decision, then accessibility and image rights.

Imprint. A business web presence regularly needs an imprint under Section 5 of the German Digital Services Act (DDG). "The website is free" is no counterargument. The information must be easily recognisable, immediately reachable and permanently available, in practice as a clearly labelled footer link on every page. This includes name and a serviceable address, an email address for fast contact and, depending on the provider, register data, VAT ID or professional-law details. Three common mistakes: a PO box does not replace a serviceable address, a regular tax number is not a VAT ID, and a disclaimer does not remove a statutory duty. A mailto link alone is not enough, the email address must be written out. Since 20 July 2025 the EU-OS platform no longer exists, old linking obligations to it can be removed.

Privacy. Privacy does not start with the contact form: even the technical provision of a website usually processes personal data such as IP addresses in server logs. The privacy notice must match the actual processing. First take stock: host, CDN, form, analytics, embedded fonts, videos, captchas. For each process record data, purpose, legal basis, recipients and retention period. A generator can serve as a working aid but does not replace checking whether all actual processes are correctly described.

Cookie banners. The myth "every website needs a banner" is wrong. Two separate layers matter: if information is stored on or read from the end device, consent is generally required under Section 25 TDDDG, with exceptions for strictly necessary operations. In addition, every processing of personal data needs a legal basis under the GDPR. A deliberately simple website without tracking and without third-party services can get by completely without a banner. Where a banner is needed, it must work technically: operations requiring consent must not run before the decision, and declining must be as easy as accepting. A court required an equally visible "reject all" button on the first level next to an "accept all" option. A notice "by continuing to browse you agree" is not a defensible solution.

Accessibility. The German Accessibility Strengthening Act (BFSG) applies since 28 June 2025 but is not a blanket duty for every website. It covers certain consumer services, above all electronic commerce, i.e. online shops and bookable transaction flows. Small enterprises are exempt for services, with an exact formula: fewer than ten employees AND (at most 2 million euros annual turnover OR at most 2 million euros balance-sheet total). VAT small-business status is a different concept. For covered websites: the entire affected website counts, not just the order button. And overlay tools that place accessibility on top via script cannot, according to monitoring bodies, fully remove barriers and can even create new ones. Good usability, keyboard focus, understandable forms and sufficient contrast are worthwhile regardless of the duty question: the Contrast Checker tests colour combinations against WCAG.

Image rights. A freely findable image is not free to use. Naming the author does not replace a usage licence, and with recognisable people publication and privacy questions come on top. For every image used you should keep a small proof: source, author, the concrete licence with version and retrieval date, permitted uses. Before publishing, it is worth a look into the file metadata: the Image Metadata Remover cleans EXIF data, and the Metadata Inspector shows what a file contains. Neither creates usage rights, that clarification always comes first.

SEO basics: how your page becomes visible on Google

SEO is not point collecting, it is making sure search engines understand your content. Three terms cleanly separated: crawling means a search engine fetches your URL. Indexing means it processes the content and decides whether to include it in search. Ranking means it chooses position and presentation for a concrete query. An HTTP status 200 or a submitted sitemap guarantees no good position.

The settings that really matter at the start:

On character lengths, the honest assessment: Google states no fixed maximum length for title and description, display is truncated by available space. Key statement first, avoid repetitions. For word count there is no magic limit either, and Google does not use the keywords meta tag. And one current correction to many guides: since 7 May 2026 Google no longer shows FAQ rich results. A visible FAQ section on the page remains useful, but FAQ markup is no longer a recipe for special search presentations.

The most common launch mistake in this area is the accidental search block: the staging environment stays configured with noindex or a robots block and goes live that way. Remember the separation: robots.txt controls crawling, noindex controls indexing, and a blocked crawler never even reads a noindex rule. At launch do not blindly remove the whole block file, remove the unintended rules specifically.

Your toolbox for this: the Meta Tags Generator creates title, description and further metadata for a page, the Robots.txt Generator builds the block file with a sitemap reference, the Text SEO Analyzer shows readability and word repetitions, and the Word Counter helps with editing. None of these tools promise rankings, they check craft.

Images for the web: clarify rights, then optimise

Images are the biggest data transfer block on most pages, and the workflow is always the same: first rights and purpose, then cropping, then format and quality, then embedding.

1. Clarify rights and purpose. Only use images whose usage is cleared. That comes before any technology.
2. Crop and set display size. First choose the needed crop and the actually used width instead of embedding the camera original unthinkingly. The Image Resizer crops and scales to target dimensions.
3. Compare format and quality. Photos tolerate lossy formats well, screenshots with fine text need lossless variants. WebP is a good starting point, JPEG is the compatible alternative. The Image Compressor works directly in the browser, uploads nothing and exports JPEG, PNG and WebP. iPhone photos in HEIC format are accepted by the Image Converter and converted for the web.
4. Really compare file sizes. Look at before and after, not just the download folder. There is no blanket kilobyte rule; a freely chosen budget per image is a team goal, not a Google limit.
5. Set a meaningful file name and fitting text alternative. Describe content-bearing images concisely, purely decorative images get an empty alt attribute. The W3C decision tree distinguishes exactly these cases. Do not stuff every image with keywords.
6. Set width, height and loading behaviour. width and height reserve the space and prevent layout shifts. Lazy loading belongs to images further down, never to the likely LCP image.
7. Measure in the browser. In the developer tools check which file is actually loaded. A smaller export does not help if the CMS still embeds the original.

For format questions in detail, such as browser support and use cases, the handbook has its own article on data formats.

Performance: understanding and measuring Core Web Vitals

Google measures page experience with three metrics, the Core Web Vitals. They are evaluated at the 75th percentile, separately for mobile and desktop, so not as an average and not as the best single test.

Two distinctions prevent the most common misreadings. First lab data and field data: PageSpeed Insights shows field data from real usage over the last 28 days on one side and a Lighthouse lab analysis under simulated conditions on the other. A green lab score proves nothing about good field data, and for new or low-traffic pages field data is simply missing. Second, INP is not a load time: it looks at interactions across the whole visit, a page can load fast and still have sluggish menus.

Optimising means: measure the bottleneck first, then act specifically. The most effective levers for small websites in typical order: remove oversized images and unnecessary embeds, then minify CSS and JavaScript and check fonts, then look at hosting and caching. The CSS Minifier reduces stylesheets for delivery, and the Website Performance Playbook walks you through the tool sequence step by step. Minifying is only one building block: HTTP compression via gzip or Brotli is a separate server feature, and unused libraries remain just as large after minifying.

The launch checklist: what you check before going live

This list is a sign-off sequence, not a Google duty list. Blockers prevent a sensible release, everything after that is rework.

Blockers before go-live:

• All target pages reachable under the later public address with the right content
• HTTPS active, certificate valid, no browser warnings, no mixed content
• No accidental search block: robots meta, X-Robots-Tag, robots.txt and CMS visibility checked
• Host variant and HTTPS consistent, canonical does not point to the staging domain
• Navigation, buttons, phone numbers and email links actually tried
• Forms tested end to end, including confirmation and actual receipt
• Mobile view checked on a real device, not only in the editor simulator
• Keyboard operation, visible focus and understandable form labels checked
• No demo texts, placeholder images or wrong contact details
• Images small enough, hero image not lazy loaded, alt treatment fits
• Imprint, privacy notice and image licences professionally reviewed
• Access secured, backup available, rollback path known

Directly after switching over: open the real domain in a fresh private session and play through the main task once completely. Check metadata on the delivered HTML, not on the draft. Submit the sitemap in Search Console and have an important URL checked. Control the favicon, for that there is the Favicon Generator. And run the Website Auditor as an additional visual check: it examines status, title, description, headings, alt attributes, canonical and robots basics of the delivered HTML. Know two limits: its character-length rating is a local heuristic, not a Google rule, and it also warns on correctly empty alt attributes of decorative images. A green basic check does not replace functional, performance or legal tests.

For the technical part of the sign-off, the Dev Launch Checklist Playbook walks through code and basic SEO checks with the matching tool chain.

After the launch: observe instead of frantically optimising

The launch is the starting gun, not the finish line. In the first period three things count: tracking down errors, evaluating search queries and re-testing changes.

• Use Search Console. Verify ownership, watch indexing status, look at search queries: which questions lead to impressions, which pages are shown, do the titles fit? Search Console is free and a diagnostic tool, not a ranking purchase.
• Read field data correctly. Distinguish PSI values at URL and origin level, do not interpret missing values as failure, and keep the 28-day window in mind after changes.
• Re-check after every change. Image swaps, new plugins, video embeds or new fonts can change a once-passed sign-off.
• Maintain operations. Updates, access, backup recovery and content freshness at regular intervals, not hectically every day.

Google itself explains that some changes only become assessable over weeks or months. From that statement follows no fixed deadline "after X days on Google" but the sensible rhythm: one follow-up after a few days, a look at search and field data after a few weeks. For ongoing content work, preparing, checking and publishing texts, there is the Content SEO Publish Playbook.

Common mistakes in the first own website project

1. Reducing SEO to word count. Write for the concrete question, cut repetitions, done.
2. Confusing your own title checker with Google. A heuristic is not an official character limit.
3. Treating robots.txt as an invisibility shield. Crawling, indexing and confidentiality are three different jobs.
4. Pointing canonical at the wrong page. Only consolidate genuinely duplicate variants, do not canonicalise different articles to the homepage.
5. Assuming a submitted sitemap means indexed. A submission is a discovery aid, the status lives in Search Console.
6. Lazy loading the LCP image. A smaller image still arrives late if it is discovered late.
7. One image file for all devices. Fitting variants save unnecessary data transfer.
8. Embedding the old original after optimising. Check the actually loaded source in the developer tools.
9. Fixing every auditor warning about alt text. Decorative images specifically need an empty alt attribute.
10. Declaring minifying as the speed cure. Large images, blocking JavaScript and server response can still dominate.
11. Taking a green lab score as proof of good real usage. Lab diagnostics, field data and real functional tests complement each other.
12. Recommending FAQ markup as a visibility trick. Google has discontinued FAQ rich results; helpful answers remain sensible anyway.

Frequently asked questions about your own website

The most important questions from practice, answered briefly and with the state of research.

[The FAQ answers are in the FAQ block above on this page.]

If after the launch you want to assess the trustworthiness of a third-party website, for example before an order, the guide checking website trustworthiness helps. And for data protection when using online services without your own account, the handbook has its own article on services without an account.