# Website checklist before go-live: what we check before a website is allowed to go online > URL: https://4eck-media.de/en/blog/website-checklist-before-go-live-what-we-check-before-a-website-is-allowed-to-go-online/ > Language: en > Description: There is a moment that everyone who builds websites knows. The project is "finished". The colours are right, the images sit well, the client applauded the design in the meeting, a… --- There is a moment that everyone who builds websites knows. The project is “finished”. The colours are right, the images sit well, the client applauded the design in the meeting, and in the project chat the question appears: “Can we go live this week, then?” Everything in me wants to say yes. And it is at exactly this point that the part of our work begins that almost nobody ever talks about. Because between “looks finished” and “is finished” there is a list. Ours has grown over the years, and almost every point on it has a backstory: a hero image that cut off the managing director’s head on the iPad. A contact form that displayed a green success message and still did not deliver a single email. A heading that ran off the screen because of one single long German word. None of it could be seen in the design. All of it could be seen live. ![](https://4eck-media.de/wp-content/uploads/2026/07/website-checkliste-vor-go-live-qualitaet-statt-pfusch-cover.avif) For the client, a website in a moment like this is not 95 per cent finished. It is broken. They do not distinguish between design, front end, hosting and content maintenance. They see a website, and every error carries their company’s logo. That is why we are publishing our complete internal checklist for the period before go-live here. It is not secret knowledge, and that is precisely the point: the difference between a professional website and an after-hours project is rarely talent. It is discipline. In our agency there is no “that’ll do” and no “it looks fine, though”. A point is either done or it is not. There is nothing in between. This article covers everything that is checked before publication. For the period afterwards there is a second list and a [separate article about the checks after go-live](https://4eck-media.de/en/blog/website-launch-checklist-what-separates-quality-from-botched-work-after-go-live/), because a website that is online is far from finished. Both parts continue and deepen what Matthias began in 2023 in our comprehensive [relaunch checklist for online shops, booking and corporate websites](https://www.tutkit.com/de/blog/203-relaunch-checkliste-fuer-online-shops-buchungs-und-corporate-websites). Finished is not the same as checked - Design approval means: the direction is right. It does not mean that every device has been tested. - A go-live test assesses function, presentation, technology and findability together. - Before the launch you prepare; after the launch you confirm under real production conditions. - Every check point needs a responsible person and a traceable result. - If the client finds the error first, quality assurance was not finished. ## One design, four truths: desktop, notebook, tablet, smartphone Websites are built on large, calm monitors and used on small, restless devices. That is the fundamental problem with almost every design sign-off. The draft was shown and approved on 27 inches. The visitor arrives with a three-year-old smartphone, holds it in one hand and has half a minute of patience. That is why we check every project on four device classes, and not just the home page. Service pages, blog articles, forms, overviews, and for shops the product and checkout pages: every template has its own breaking points. Checking only the home page is not a website check. It is a home page check. ![Responsive web design of the Bolzakademie on tablet and smartphone with an identical home page](https://4eck-media.de/wp-content/uploads/2026/07/responsive-webdesign-bolzakademie-tablet-smartphone-startseite.avif) ### Desktop and notebook: the first screen decides On large monitors I watch out for text lines that are too long, content lost in vast areas of white space and containers that drift apart without a maximum width. A layout that looks balanced at 1440 pixels can fall apart on a 27-inch display. The notebook is not simply a scaled-down desktop. At 13 to 15 inches, height is the real problem: the browser bar and the operating system take up space, and a hero that looks elegant on the monitor occupies the entire visible area on a notebook. I therefore check the first screen like a visitor: is it immediately clear what this is about? Is the most important button within reach, or is it hidden by cookie banners and sticky headers? Can you even tell that there is more further down? ### Tablet: the awkward middle ground In many projects, tablets are tested last. Desktop is important, mobile is important, and whatever lies in between will surely be fine. That is exactly where the ugliest errors arise: a tablet is wide enough to activate desktop rules, but too narrow to accommodate their content cleanly. Two columns get squeezed, the navigation only just no longer fits on one line, images lose their focus. For that, our list names the iPad mini and the iPad Pro, not out of brand loyalty, but because we need two clearly different size classes and repeatable test conditions. And I deliberately rotate the device: an iPad Pro in landscape is almost a notebook. The same iPad in portrait sets completely different tasks for heroes, tables and card rows. ### Smartphone: not narrower, but different On the phone, a website is operated with the thumb, under time pressure, often on the move. Simply stacking a desktop layout is not enough. Content has to be prioritised, buttons need real touch areas, forms have to open the right keyboard, phone numbers have to be tappable. Our reference devices are the iPhone 12 and the iPhone 14 Pro plus simulated viewports in the browser. Real devices nevertheless remain mandatory, because no simulation fully reproduces browser bars, touch behaviour and real performance. A single element with a fixed width makes the whole page scrollable horizontally. A popup whose close cross lies outside the screen blocks the visitor completely. And the question we ask is never just “Is everything visible?”, but: does the important content appear early enough? Can you hit the link without catching the one next to it? Does the error message appear at the affected field or somewhere outside the visible area? Many quality problems are not spectacular enough for a bug report. They simply create friction, and later on all you see in analytics is the poorer conversion rate. ## Hero images: the half hour nobody sees in the quote I love our designers. I really do. But an image spanning the full screen width is almost always a technical compromise and regularly a small battle. In the draft the hero sits perfectly on its fixed area. In the browser that area does not exist: one visitor holds a tablet in portrait, the next sits in front of an ultrawide monitor, and both are meant to see the same face, the same product, the same line in the right place. Technically we solve this with several image sizes: our theme works with six layout levels: a mobile base and the widths from 576, 768, 992, 1200 and 1710 pixels. Using srcset and sizes, the browser selects the appropriate AVIF variant instead of loading the largest original everywhere. That solves the file size. It does not solve the image composition: object-fit fills the area, but something always gets cropped. With object-position I determine which area survives. That only works if I really look at the subject in several aspect ratios. On top of that there is a conversation I have regularly: “But we sent high-resolution material.” What is meant is Full HD. 1920 by 1080 pixels sounds big, but for a full-width image on a large Retina display it is simply too little, and if a crop still has to be chosen, even fewer real pixels remain for the visible area. The result is a hero that looks clean on the notebook and soft on the large monitor. Of course AI can upscale. That rescues some subjects, but it invents details: hair, hands, lettering and building facades are typical problem areas. If the material does not provide the resolution, I do not promise magic: in that case we change the crop, the area or the hero type. That is not a defeat for the design. It is an honest decision. For one single difficult hero, 30 minutes quickly add up in total: check the file, generate variants, set the focus, rotate the tablet, test ultrawide, correct the contrast, export again. Nobody sees that half hour later on. If it is missing, everybody sees it. Our hero rule - A full-width hero needs a subject with sufficient reserve, up to 4K if in doubt. - The original is not loaded everywhere: the theme, srcset and AVIF deliver suitable variants. - Crop and object position are checked on mobile, tablet, notebook, desktop and ultrawide. - AI upscaling is checked for artefacts and not confused with genuine detail resolution. - Full width preferably on the home page; sub-pages get a more robust second hero type. ## Browser test: Chrome alone is not an approval Every developer has a favourite browser, and usually it is the one they also develop in. That is normal. It becomes problematic when that same browser is also the only quality control. Chrome, Firefox, Safari and Edge largely speak the same standards today, but not in every detail: fonts are rendered differently, form fields look different, sticky elements react differently in borderline cases, and Safari cultivates its historical quirks. That is why our checklist explicitly names all four browsers, and we check the components with the greatest risk of error: navigation, dropdowns, sliders, video, cookie banners, forms, accordions, tabs, modal windows, sticky elements, animations. We test Safari on a real Apple device: a Chromium simulation is no substitute for the WebKit engine. Typical findings: a font that does not load and shifts all the line breaks; a video that stalls because of autoplay rules; a focus state that disappears. In doing so we do not try to serve every browser version of the past ten years; what is relevant is defined before the project begins. But simply not opening the browsers that are currently in widespread use is not a technical decision. It is hope. ## Long headings and ­: the error that is guaranteed to turn up at the client’s German compound nouns are brutal for narrow screens. “Suchmaschinenoptimierungsstrategie” or “Barrierefreiheitsstärkungsgesetz” blow up entire layouts. Automatic hyphenation via CSS helps, but it depends on the browser, the language and the dictionary. It is not equally reliable everywhere. That is why we insert soft break points into critical headings by hand: the invisible character ­. As long as there is room, you see nothing. If the browser has to break the line, it breaks it in the right place and shows a hyphen. ![Faulty display of long words on the smartphone without soft hyphens set](https://4eck-media.de/wp-content/uploads/2026/07/exec-c87f6807-ca83-4308-bb28-8c5279f93b3f.avif) Why go to the trouble? Because this error has a special quality: it never appears on my test device. It waits for that one client with that one display width and the enlarged system font, and then comes the screenshot with the friendly question of where exactly we had been looking. With long German headings, “it’ll break somewhere” is not a test procedure. ![Before-and-after graphic: a long word runs off the smartphone screen without a soft break point, with shy it breaks cleanly](https://4eck-media.de/wp-content/uploads/2026/07/soft-hyphen-long-headlines-mobile.avif) ## Legal notice, privacy policy, accessibility statement and the favicon A website can be outstanding in design terms and still start out flying blind legally. Before go-live, the legal notice (Impressum) and the privacy policy have to be created, linked and reachable from every page, and the links must not be covered by the cookie banner of all things. This also includes the page with the accessibility statement, which we create for every project: it documents the standard the website meets, and, like the legal notice and the privacy policy, it belongs in the footer. What matters here is being honest about responsibilities: we build the technical foundation, enter the texts supplied to us and check the linking. We do not replace the legal sign-off of the legal texts. And the privacy text has to match the real website: analytics, external videos, maps, newsletters, captcha: whatever is actually embedded also has to be described. A text about a theoretical standard website is no help if the live site has different data flows. And then there is the favicon, the smallest point on the list and the one most reliably forgotten. If it is missing, the tab shows a generic symbol or the icon of the development environment: nothing is broken as a result, but it still looks unfinished. I check the tab, the bookmark and the mobile display. And the motif has to survive being scaled down: a fine piece of lettering is nothing more than a smudge at 16 by 16 pixels. ## Accessibility: design approval alone is not enough Accessibility begins in the design (contrasts, font sizes, focus states, logical structure) and does not end there. New problems arise during development and content maintenance: an editor uploads an image without alt text, a heading skips levels, a form is given a misleading label. That is why, before go-live, we run another automated check (our list names AccessibilityChecker and AccessScan) and supplement the scanners with manual spot checks. Because a scanner can measure whether an alt text exists. Whether it describes the image meaningfully is beyond it. I therefore navigate through the navigation, forms and dialogues without a mouse myself, follow the visible focus, check the heading hierarchy and provoke form errors: does the message appear at the field, and can it be understood? Does the page remain usable with zoom and a larger font? Since the German Accessibility Strengthening Act (Barrierefreiheitsstärkungsgesetz) of 28 June 2025, this has also been a legal question for many offerings. Which obligations apply specifically depends on the company and, in case of doubt, has to be clarified legally. My practical stance is independent of that: accessibility is part of professional web development today, just as HTTPS is. Incidentally, it is not a blanket Google ranking factor, but much of what it requires (a clean structure, mobile usability, understandable content) helps search engines and conversion at the same time. If you want to tackle the topic seriously, you will find our approach at [accessible websites](https://4eck-media.de/en/competencies/accessibility-for-your-websites-web-design-agency/). ![WCAG 2.2 audit of the Bolzakademie website with 90 out of 100 points and zero critical errors](https://4eck-media.de/wp-content/uploads/2026/07/barrierefreiheit-wcag-audit-website-bolzakademie-rostock.avif) ## OG data: the first impression is often formed in WhatsApp Before a visitor sees the website, they often see only its preview: as a shared link in WhatsApp, LinkedIn, Slack or Teams. This preview is built by the Open Graph data: og:title, og:description and above all og:image. If these are not maintained, the messenger pulls some image or other out of the page, cuts off the title or simply shows nothing at all. The first impression of the new website is then a grey box. ![Comparison graphic: link preview in the messenger without OG data as a grey box, with OG data as a card with image, title and description](https://4eck-media.de/wp-content/uploads/2026/07/og-data-link-preview-messenger.avif) Before go-live I therefore check for each template: is a preview image set, does it have the right size (1200 by 630 pixels as standard), does it show the right thing, and are the title and description correct? Particularly important after a relaunch: the OG URLs must no longer point to the development domain. The test is simple: drop the link into a messenger or a preview tool and look at what actually appears. It takes minutes and determines what every shared recommendation of the website looks like. ![OpenGraph check of the Bolzakademie website with a correctly embedded OG image](https://4eck-media.de/wp-content/uploads/2026/07/og-image-seo-monitor-mockup-16x9-1-e1784893939736.avif) ## Structured data: the instruction manual for machines With structured data we describe the website in such a way that machines do not merely see words, but relationships: “4eck Media” is then not a string of characters but an organisation with an address, services, people and reviews. The widespread minimal approach (install an SEO plugin, add a logo, done) creates a basic framework. We go considerably further and model the real website: organisation, founders, employees, service catalogues, articles with author and date, breadcrumbs, FAQ. Not with invented details, but with verifiable ones. In the context of AI search in particular this pays off: systems such as ChatGPT, Gemini or Perplexity have to be able to assign companies, people and services unambiguously. Structured data does not guarantee a recommendation. It reduces ambiguity. Before go-live I validate with the Schema.org validator and, where Google supports a type, with the Rich Results Test. And then comes the check that no validator takes on: the comparison with reality. If the footer shows a different phone number from the markup, the code is technically valid and factually wrong. Markup is also not a one-off piece of decorative code: if the address, the team or the services change, the machine-readable layer has to follow suit, otherwise at some point it will produce particularly precise outdated information. Markup: our minimum standard - Model not just WebSite and Organization, but all relevant real entities. - Connect companies, people, services, articles, navigation, breadcrumbs and FAQ with one another. - Mark up only visible, correct and verifiable information. - Check JSON-LD with the Schema.org Validator and, where applicable, Google’s Rich Results Test. - Maintain markup when things change, exactly as you do with visible content. ## PageSpeed: 90 is the lower limit, not the goal PageSpeed is the point where I am reluctant to negotiate. With us, a new website starts in the green: at least 90 points in Google PageSpeed Insights, with 94, 95 and more as the target. Not because there is a different world between 93 and 95, but because we need reserve. After handover the website goes on living: at some point the client uploads a 12-megabyte photo, embeds a video, adds a marketing script. Anyone who starts at exactly 90 is in the amber after the first careless change. Anyone who starts at 95 can cope with everyday life. I measure mobile and desktop separately, and mobile is the more honest test: weaker CPU, poorer network, larger images. Behind the score I look at the Core Web Vitals: LCP (when is the largest element visible? Usually it is precisely the hero image from earlier), INP (how quickly does the page respond?) and CLS (does the layout jump while loading?). A score of 100 with a broken presentation is worthless, but the reverse statement “PageSpeed is only a tool, after all” does not wash with me either: the tool shows real risks. The classics are almost always the same: images that are too large, blocking JavaScript, late-loading fonts, third-party scripts. How we tackle this systematically is described on our page on [PageSpeed optimisation](https://4eck-media.de/en/competencies/pagespeed-optimization-making-websites-measurably-faster/). ![Google PageSpeed Insights report for the Bolzakademie website with an assessment of the loading time](https://4eck-media.de/wp-content/uploads/2026/07/pagespeed-optimierung-ladezeit-website-bolzakademie-rostock.avif) ## Yoast and Seobility: tools find what eyes overlook Before go-live we check the basic Yoast settings and additionally have the entire website crawled. For that we use Seobility. The crawler answers a question that no human being can answer just by looking: is there a page somewhere that is out of line? An example from one of our recent projects: the “Technology & Meta” area stood at 98 per cent. Sounds finished. The missing two per cent were two problematic meta descriptions, one heading anomaly and three missing alt attributes: precisely the handful of concrete errors this check exists for. A high overall score is no reason to ignore the remaining list. It is the reason why the remaining list is short. In Yoast I also check the templates: a single well-maintained article proves nothing if an entire custom post type is accidentally set to noindex or automatically generates unusable titles. And in the crawl I pay attention to structure: important pages buried five clicks deep; link texts such as “more” that tell nobody where they lead; orphaned pages. A tool measures paths. Whether the paths make sense is decided by a human being. If you want to go deeper: for the big all-round view there is the [SEO audit](https://4eck-media.de/en/competencies/seo-audit-for-your-website-analysis-optimization-plan/); before go-live it is about the obvious errors that can still be fixed cheaply now. ![Seobility analysis of the Bolzakademie website with a 96 per cent on-page score](https://4eck-media.de/wp-content/uploads/2026/07/seo-onpage-optimierung-analyse-website-bolzakademie.avif) ## Forms and emails: submitting is not yet delivery The contact form is the place where an apparently passed test is most dangerous. The developer fills it in, sees the green success message, tick. Exactly one thing has been proven by that: the front end has accepted the enquiry. Whether an email arrived in the right mailbox, whether the confirmation went out to the sender, whether the data was saved. All of that is open. We have had the case in practice: form green, mailbox empty. The client only notices something like that when they start wondering why nobody has made an enquiry for two weeks. That is why I test the complete path: mandatory fields have to take effect, invalid entries have to be caught comprehensibly, the message has to land in the intended mailbox (not in spam), and the sender name, subject, reply-to and all fields have to be formatted sensibly. For reliable delivery we set up an SMTP or transactional mail route; SPF, DKIM and DMARC lie partly outside WordPress but also determine whether the message is considered trustworthy. I test business-critical forms with several addresses and on the phone. And the spam protection is prepared, but it must not block real people. The fine-tuning follows after the launch. ## Redirect map: plan before the relaunch, do not improvise afterwards With a new domain that has no predecessor, this point is a small one. With a relaunch, the redirect map is one of the most important documents in the project: every relevant old URL is given a sensible new target: not the home page across the board, but the closest replacement in terms of content. I collect the old URLs from the sitemap, analytics, Search Console and the crawl, we assign targets and mark what is deliberately being dropped. Chains and loops are dangerous: if A points to B and B later points to C, unnecessary detours arise: better to send A straight to C. A loop makes the target completely unreachable. The map is prepared before go-live; it is tested definitively on the live domain. That way we make the decisions calmly and not at the moment when the old website has already been switched off. ![Diagram: redirect chain A via B to C, direct redirect A to C and redirect loop between A and B](https://4eck-media.de/wp-content/uploads/2026/07/redirect-chains-loops-diagram.avif) ## Updates, tidying up, login path and photographic evidence Before go-live we bring WordPress, the theme and the plugins to a coordinated, up-to-date state, but not five minutes before knocking-off time and never without a restore point. Updates change code; they close gaps and can just as easily introduce new conflicts. So: back up, update in the development environment, repeat the critical tests. Tidying up is just as important: test plugins, demo imports and unused themes are thrown out. The best number of plugins is not zero, but the smallest number that reliably fulfils the agreed tasks. Our list also states that the login path should be changed from /wp-login to a project-specific path. That keeps automated background noise away and is expressly not a security concept. A hidden login with the password “admin123” is not secure. Strong passwords, two-factor authentication, limited login attempts and minimal permissions remain the actual protection; test accounts are removed before the launch. And with every relaunch we take screenshots of the old website: home page, important sub-pages, navigation, forms. That sounds like nostalgia and is practical insurance: after the switch the old state is gone, and otherwise the discussion from memory begins: was this text already like that before? Was there this note? A before-and-after comparison answers such questions in seconds. ## Translations: every language is a website of its own With a multilingual website it is not enough to check the German version and trust the translation plugin. Texts differ in length: a terse German button becomes wide in French, an English heading fits on one line while the Polish one needs three. Menus, forms, SEO fields and alt texts can have their own gaps in each language. I therefore treat every language like a separate website: navigation, language switcher, key pages, forms, metadata, hreflang. A single German button in an English enquiry journey is enough for the visitor to know: the work here was not finished. And the most important lesson from our own practice: the status “complete” in the translation tool is no proof: we have seen fields that were marked as translated and were nevertheless empty. How we translate large websites today using XLIFF and AI, and check ourselves while doing so, is described in the [complete guide to WordPress translation with AI](https://4eck-media.de/en/blog/translating-wordpress-with-ai-fast-cheap-and-without-the-wpml-frustration-our-complete-workflow/). ## How we check: names, priorities, evidence The best checklist is no help if it sits next to the project as an anonymous spreadsheet. With us, every point has a name: who checks forms, who checks the translations, who checks the devices. And a point knows four states: checked, error found, corrected, checked again. A bug is not done because somebody writes that they have fixed it; the correction can break something new elsewhere. Only the retest closes the point. Errors are prioritised, otherwise somebody spends three hours polishing a two-pixel gap while the form is not sending any mail: critical is whatever blocks a central user journey. Serious is whatever affects an important device class or legal obligations. The rest is documented and planned. And every finding needs usable evidence: “mobile is broken” is not information. “At 390 by 844 pixels in Safari, the cookie button sits on top of the submit button” can be reproduced and fixed. Two more rules that have often saved us. First: whoever built a function does not sign it off on their own: the builder knows where to click, and that is exactly why they overlook the hurdles. For central journeys, the four-eyes principle applies. Second: the client’s approval does not replace our check. The client approves the design and the content; they are not our unpaid quality assurance. If they spend their review time on browser bugs that we should have found ourselves, we have wasted their attention. What such a check looks like in practice is shown by Matthias in this video: an AI-built website, professionally taken apart: 10 errors in 20 minutes. [KI-Website besser als 95 % der Webdesigner? 10 Fehler in 20 Minuten aufgedeckt.](https://www.youtube-nocookie.com/embed/j6MsRVOb2do?feature=oembed) My benchmark before go-live - No device is ticked off with the phrase “it’ll be fine”. - No tool score replaces the visible and functional check. - PageSpeed starts green and with reserve for later maintenance. - Markup, accessibility and SEO are components of development, not decoration afterwards. - The website only goes live when I can also explain the result on the client’s device. ## The complete before-live checklist at a glance The overview is the condensed version of our internal working list. In the project it is supplemented with specific functions: a corporate website does not need a checkout test, a shop needs considerably more of them. Copying is expressly welcome. And assign a name to every point. A tick without someone responsible is just an empty cell. | Check point | What specifically has to be confirmed | Typical consequence without a check | | --- | --- | --- | | Desktop design | Spacing, containers, text widths, page rhythm and all templates | The home page looks good, sub-pages look unfinished | | Notebook design | First visible area, hero height, sticky header and buttons | Important content lies entirely below the fold | | Tablet small and large | Portrait and landscape, columns, navigation, tables, sliders | Squeezed intermediate layouts and cropped subjects | | Mobile | Touch areas, order, popups, forms and horizontal scrolling | Visitors cannot operate key functions | | Hero images | Resolution, responsive variants, crop, focus and contrast | Mushy images, artefacts or vanished main subjects | | Legal notice and privacy policy | Content supplied, linked globally, technical services taken into account | Legal and trust-related risks | | Accessibility | Scanner plus keyboard, focus, structure and zoom test | Exclusion of users, correction costs and possible legal risks | | Favicon | Browser tab, mobile display and suitable reduction | The site visibly looks unfinished | | Structured data | Real entities modelled completely, validly and without contradictions | Search engines and AI receive unclear or incorrect signals | | PageSpeed mobile | At least 90, target 94-95+, causes and Core Web Vitals checked | Slow use and no room for later content | | PageSpeed desktop | Separate run, resources, layout shifts and scripts checked | Problems are masked by the fast development machine | | Yoast | Indexing, canonical, templates, title and description | Entire content types are indexed incorrectly | | Seobility | Technology, structure and content crawled; anomalies assessed | Serial errors and forgotten pages remain undetected | | Forms and emails | Validation, delivery, reply-to, confirmation and mobile | Enquiries disappear despite a green success message | | Redirect map | Old URLs collected and each assigned a sensible target | 404 errors, ranking losses and frustrated existing users | | WordPress and plugins | Updated in a controlled way, tested and unnecessary components removed | Security gaps and conflicts immediately after the launch | | Browsers | Chrome, Firefox, Safari and Edge with critical functions | The error hits precisely those users outside the development browser | | Login and users | Path, 2FA, passwords, permissions and test accounts | Unnecessary attack surface and overly broad access rights | | Screenshots of the old site | Important pages and functions documented before the switch | Before-and-after questions can no longer be answered | | Translations | Every language checked visually, functionally and in the SEO fields | Language mix, broken line breaks and incomplete user journeys | | ­ in headings | Long German words given sensible break points | Some smartphone or other is guaranteed to find the embarrassing line break | ## What distinguishes quality from technical botch-work Technical botch-work is rarely spectacular. Most of the time it is a hero that cuts off the head on the iPad. An enquiry that was never delivered. An H1 that runs off the screen because of a long word. Every single error can be played down. Together they decide whether a visitor trusts the website. For me, quality does not mean freedom from errors for all eternity. Quality means: checking known risks systematically, documenting decisions and going live with a state you can stand behind with a clear conscience. You can do this work yourself. That is precisely why the list is here in full. You need patience, real devices and the willingness to take another critical look at a supposedly finished page. If you would rather hand it over, you can [have a professional website developed](https://4eck-media.de/en/competencies/ui-ux-web-development-agency-4eck-media/) or contact us via the [4eck Media contact page](https://4eck-media.de/en/contact/) for a technical check. And once the website is online? Then the second half of the work begins: releasing indexing, security headers, backups with a restore test, tracking and consent, redirects under real conditions. All of that is in the second part: the [launch checklist for the time after go-live](https://4eck-media.de/en/blog/website-launch-checklist-what-separates-quality-from-botched-work-after-go-live/). Incidentally: with multilingual projects, translation is part of quality assurance too. How we [translate WPML with AI](https://4eck-media.de/en/blog/translating-wordpress-with-ai-fast-cheap-and-without-the-wpml-frustration-our-complete-workflow/) (quickly, inexpensively and verifiably completely) is described in our complete workflow article. ## Frequently asked questions about the website checklist before go-live What do you have to check before a website goes live? At the very least the presentation on desktop, notebook, tablet and mobile, the most important browsers, forms and email delivery, PageSpeed, accessibility, SEO fundamentals, structured data, legal pages, plugins, redirects and (for multilingual websites) every language version. Project-specific functions come on top of that. How long does a professional website check before the launch take? That depends on the scope and the functions. A small website can be checked in a few hours; a shop, portal or multilingual relaunch takes considerably longer. A difficult full-width hero alone can cause around half an hour of additional work through cropping, responsive variants and device tests. Is it enough to test the website in Chrome? No. Chrome, Firefox, Safari and Edge still differ in rendering, forms and individual CSS or JavaScript functions. Critical components have to be run in the agreed target browsers. Safari should be checked on a real Apple device. Which PageSpeed score is good before go-live? Our minimum value is 90, our target is 94 to 95 or higher. The additional margin creates reserve when larger images, videos or marketing scripts are added later. Alongside the score, the causes and the Core Web Vitals LCP, INP and CLS are decisive. Is accessibility a direct Google ranking factor? Google does not describe accessibility across the board as a single direct ranking factor. Core Web Vitals are, however, used in the ranking systems, and many characteristics of an accessible website (mobile usability, a clear structure, semantics and understandable content) improve usability and technical processability at the same time. Why is structured data so important before the launch? Structured data describes companies, people, services, articles and their relationships in a machine-readable way. This reduces ambiguity for search engines and AI systems. Markup does not guarantee a ranking, but it should be complete, correct, valid and consistent with the visible information on the website. What else has to be considered with a website relaunch checklist? With a relaunch, the export of old URLs, a redirect map, the reconciliation of analytics and Search Console, screenshots of the old website and the checking of canonical, sitemap, indexing and existing rankings are added in particular. The visual and functional before-live check nevertheless remains fully in place.