# Website launch checklist: what separates quality from botched work after go-live > URL: https://4eck-media.de/en/blog/website-launch-checklist-what-separates-quality-from-botched-work-after-go-live/ > Language: en > Description: There is one word that sets off a small cheer in every project chat: "live". The domain points to the new server, the padlock is showing in the browser, the home page loads. And i… --- There is one word that sets off a small cheer in every project chat: “live”. The domain points to the new server, the padlock is showing in the browser, the home page loads. And it is precisely at this moment that a quiet mistake happens in many projects: everyone celebrates and nobody carries on checking. Yet this is exactly when the phase begins that decides whether the project is properly completed or whether the client spends the next few weeks working as an unpaid tester. I have little time for the sentence “Let’s put the site online now and then see whether anything else comes up.” Of course something else will come up. After launch, a website runs under different conditions than in the development environment: a real domain, real SSL, public caching, real mail servers, consent management, search engines, bots, visitors. These differences are normal. What is not normal is leaving them to chance. ![Cover image of the website launch checklist with clipboard, football and check points after go-live](https://4eck-media.de/wp-content/uploads/2026/07/website-launch-checkliste-nach-go-live-cover.avif "Website launch checklist: important steps after go-live") That is why we keep a second list. Everything that [has to be checked before publication](https://4eck-media.de/en/blog/website-checklist-before-go-live-what-we-check-before-a-website-is-allowed-to-go-online/) was described in part 1. This article begins where part 1 ends: on the real domain, under real conditions. And this list is no secret either: anyone who runs a WordPress website themselves can work through it point by point. You do not need a magical agency tool. You need time, clear responsibilities and the willingness not to gloss over uncomfortable results. Incidentally, we never launch at 16:55 on a Friday. A go-live takes place when the developers, the project management and, if need be, the hosting provider can all be reached. Afterwards there is no celebrating, there is checking. You can celebrate later, and far more comfortably. And if you are not just launching but planning a complete relaunch: the strategic level has been documented since 2023 in our extensive [relaunch checklist on TutKit](https://www.tutkit.com/de/blog/203-relaunch-checkliste-fuer-online-shops-buchungs-und-corporate-websites). These two articles are its continuation in practice. Online is not the same as finished - The production environment changes the domain, SSL, cache, email, tracking and external services. - Prepared settings are checked again on the real URL. - Critical functions are not merely looked at, they are executed in full. - The launch is given a time slot with responsible people who are reachable. - A tick only counts once the result is documented and reproducible. ## Switching off the development site: the website has to be genuinely public The first point sounds almost laughable until you have seen how often it is forgotten. After the launch there must be no maintenance page, no coming-soon page and no password protection left in front of the website. And I never check this in my normal browser: cookies and my WordPress session can make sure that I see the real site while every new visitor is still faced with a barrier. So: private window, second device, ideally a different connection. And not only the home page, but subpages, a post, a form as well. The old staging environment stays alive throughout, but cleanly separated: protected, set to noindex, outside the sitemap. A freely accessible copy of the website produces duplicate content, often contains test data and is an unnecessary attack surface. In a relaunch I additionally check which version the domain is actually serving at that moment: DNS and caches take time, and individual visitors may still see the old site. That cannot be prevented to the minute, but you have to know about it before you start collecting error reports. ## Allowing indexing: the most dangerous checkbox in WordPress Under Settings, Reading, WordPress has an inconspicuous option: “Discourage search engines from indexing this site”. During development that checkbox makes sense. After the launch, a forgotten checkbox in that spot is the single most expensive mistake a new website can have: it is online, it works perfectly and, for Google, it simply does not exist. I do not rely on the label in the back end. The option is only one signal; plugins and server rules can generate noindex instructions of their own. So I check the source code of the most important page types, the HTTP header X-Robots-Tag, the robots.txt and the XML sitemap. The aim is not to release everything wholesale, but to make a clear decision per page type: the home page, service pages and posts have to be indexable; internal search pages, the basket or technical archives are deliberately kept out, depending on the project. After a domain change I also look for leftovers of the development address: canonical tags, OG images, structured data, internal links and sitemap URLs must no longer point to dev. or an agency subdomain. A single wrong canonical tells Google that the freshly launched site is merely the copy of a test address. To round off this point I use the URL inspection tool in Google Search Console. The live test answers the decisive question: can Google retrieve the page, is it allowed to be indexed, and which canonical URL is recognised? Immediately after the launch the index often still shows the old state. That is not a problem, that is physics. The live test separates a normal “not re-crawled yet” from a genuine technical fault. The sitemap is submitted, and in the weeks that follow I regularly look at indexing reports and 404 statistics. Anyone who only opens Search Console three months later overlooks a solvable problem for three months. ## Finalising Yoast: check templates rather than individual pages The basic Yoast settings have already been checked before the launch. That is covered in part 1. On the real domain it is now about the output: I open several representative pieces of content and check whether titles are sensibly structured, whether the domain is correct everywhere and whether any placeholders remain visible. The templates are what matter: a single well-maintained article proves nothing if categories, service pages or an entire custom post type inherit incorrect meta data or an accidental noindex. I check at least the home page, a normal piece of content, an archive and every important content type, and on multilingual websites in every language. For me the Yoast traffic light is an indication, not a verdict on quality. A text can be green and still sound interchangeable. What matters more is the technical output: is the title unambiguous? Is the description missing on a central page? Does the social preview show the right image? ## Accessibility on the real domain: the cookie banner is the first impression Why look at accessibility again when it was already checked before the launch? Because new elements appear at go-live: cookie banners, tracking dialogues, captchas, chats, security solutions. And of all things, the consent dialogue sits on top of the entire website. That makes it functionally more important than almost any content block. If the website’s first dialogue cannot be operated by keyboard, if the focus disappears behind it or if “Reject” has been styled so that it is barely legible, then the most beautifully accessible subpage behind it is worthless. That is why I run AccessibilityChecker and AccessScan on the production site once again and save the result with the date. A report like that is not a lifelong certificate: the very next plugin update can change the situation. It documents a point in time, and that is exactly what it is for. On top of that come the manual steps from part 1, now on the live site: navigate without a mouse, follow the focus, provoke form errors, test zoom. If you need support with this, our approach is described under [accessibility of 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) ## PageSpeed in production: only the real domain tells the truth You know the target values from [part 1](https://4eck-media.de/en/blog/website-checklist-before-go-live-what-we-check-before-a-website-is-allowed-to-go-online/): at least 90, ideally 94, 95 and above. The buffer is deliberate. What is new after the launch is the environment. On the real domain, the CDN, caching rules, consent manager and all the third-party scripts come together that were often missing in staging or were running in test mode. A measurement taken before the consent manager is activated is simply not comparable with one taken afterwards. I measure with [PageSpeed Insights](https://pagespeed.web.dev/), mobile and desktop separately and several times over: first the cold request, then the repeat request. If the results fluctuate strongly, the fluctuation itself is the finding: a fast website is not only fast in the best case. And I do not measure only the home page: service page, blog article, overview, contact page, and for shops the product page and checkout. Every template loads different images and scripts; a lightning-fast home page proves nothing about a product filter carrying several megabytes of JavaScript. Incidentally, field data from real users is still missing immediately after the launch, or it relates to the old website. That, too, is normal. For the first week what counts is the lab data and the causes behind it: LCP, INP, CLS. Details of our approach can be found on the page about [PageSpeed optimisation and the Core Web Vitals](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) Our PageSpeed buffer - 90 points is our minimum value, 94 to 95 or more is our starting target. - Mobile and desktop are measured separately and across several page types. - LCP, INP and CLS matter more than an isolated overall score. - Several measurements show whether the result is stable or merely good by chance. - The buffer protects the green zone against later images and marketing scripts. ## Security headers: check the protection without chasing a school grade Security headers are rules that the server passes to the browser: enforce HTTPS, prevent embedding by third parties, restrict script sources. Many of them can only be checked meaningfully on the public domain. We use [SecurityHeaders.com](https://securityheaders.com/) for this, and let me be honest about it: the grade there is an indication, not an end in itself. An extremely strict content security policy that also happens to block the payment provider, the video or the consent manager is not a successful security measure. It is a new fault with a better score. As a minimum I assess Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and frame protection. And after every change the website is tested functionally: form, videos, maps, consent, fonts, plus a look at the browser console for blocked resources. Headers are active rules, not decoration. That is precisely why they must be neither ignored nor copied thoughtlessly from a template. ![Security headers report for the Bolzakademie website with the top grade A+ and all headers active](https://4eck-media.de/wp-content/uploads/2026/07/sicherheit-security-header-website-bolzakademie-bestnote.avif) ## Favicon and structured data: two short but genuine live checks In part 1 I described the favicon as the item most reliably forgotten. On the live domain there is an added quirk: browsers cache favicons astonishingly stubbornly. The fact that my browser shows the new icon does not mean that a new visitor gets it too, or the other way round. So: private window, second device, the favicon.ico address directly, light and dark browser interface. With structured data, one thing matters above all after the launch: leftovers. After a relaunch, schema graphs often still contain old image addresses, staging URLs or IDs from the test environment: the visible content sits on the new domain while the markup tells a different story. I validate the public URLs with the [Schema.org Validator](https://validator.schema.org/) and, wherever Google supports a type, with the [Rich Results Test](https://search.google.com/test/rich-results). The principle from part 1 still applies unchanged: valid does not yet mean true. Name, address, telephone numbers and images have to match what is visible on the page. Markup after the launch - Check the public URL with the Schema.org Validator and Google’s tools. - Assess errors, warnings and contradictory information separately. - Look for staging URLs, old IDs, wrong images and outdated contact details. - Only mark up information that is visible, real and verifiable. - Connect entities via stable IDs into a comprehensible graph. ## Emails and forms: everything changes on the live domain Forms were tested before the launch and are tested again from scratch after the launch. That is not pedantry: with the domain, the sender address, the SPF and DKIM relationship, the SMTP configuration, the captcha keys and sometimes the responsible mailbox all change. That is precisely why a form can work in staging and lose messages in production: silently, behind a friendly green success message. I fill in every important form like a real user: first leaving the mandatory fields empty, then with an invalid email address, then with a valid enquiry. That enquiry has to arrive in the right mailbox, not somewhere on the mail server, but with the person who is supposed to deal with it. In the inbox I check the sender name, the subject, the reply-to address and all the fields submitted; it has to be possible to reply to the visitor without a server address appearing in the recipient field. The spam folder is as much part of the test as the send logs. And on multilingual websites every language version is tested individually, including the automatic confirmation, its language and its links. And finally the uncomfortable question that hardly anyone asks: what happens if the mail service is briefly unavailable? Is the enquiry stored, retried or quietly discarded? For business-critical forms, “it should work” is not enough. The client has to know where they would spot a failure. ## Backups: set them up, check them and genuinely restore one at least once Many hosting providers advertise automatic backups. Good. But that does not answer the questions that matter in an emergency: how often is a backup taken? How long is it kept? Does the backup sit on the very infrastructure that has just failed? Are the database and the files included? Who is allowed to restore, and how long does that take? Our baseline: the hosting provider may supply the fast first tier, and on top of that a backup goes to separate storage at least daily: the client’s cloud account or, by agreement, our infrastructure. A copy on the same web space is no protection against a compromised account. And then comes the step that is missing almost everywhere: I carry out at least a spot-check restore in a safe environment. Archives can be incomplete, corrupted or dependent on a particular plugin version. If you only find that out during an outage, you do not have a backup strategy, you have a collection of files. A backup without a restore test is just hope - Agree on a hosting backup plus a separate external backup. - Back up at least daily; adjust the interval where transactions are involved. - Cover files and database together. - Document retention, encryption, responsibility and data protection. - Test a genuine restore in a safe environment. ## Seobility after the launch: crawl the entire public website Before the launch we check samples; after the launch I have the public website crawled in full. The crawler works with the real domain, the real protocols and all language versions, and it finds the typical launch leftovers: old development links, duplicate titles, missing descriptions, resources that still load over HTTP. I also check whether HTTP consistently leads to HTTPS and whether the www and non-www variants behave unambiguously. There must not be several publicly reachable versions of the same website. When it comes to structure I look less at red traffic lights and more at the question of whether the crawler finds the same website as a human being: are the central services closer to the home page than old press releases? Are there orphan pages? Do filters or archives generate thousands of unnecessary URLs? For us Seobility is not a machine for producing a pretty percentage figure, but a structured task list: work through the relevant findings, crawl again, document deliberate exceptions. An ignored error without a justification is not quality management. For the full overview there is our [SEO audit with technical and content review](https://4eck-media.de/en/competencies/seo-audit-for-your-website-analysis-optimization-plan/). ![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) ## Agent Ready: making the website readable for AI systems After the classic SEO check we now also examine a second kind of readability: the one for AI systems. There are new tools for this: agent-ready plugins, llms.txt, analyses such as Ranketic. My attitude towards them is calm: tools like these make technical gaps visible and add signals. They do not turn interchangeable advertising phrases into solid specialist information. AI systems need unambiguous statements: who offers what, for whom, in which region, with what evidence? These answers have to be in the visible content and match the markup. In concrete terms, this is what I check after the launch: are the relevant AI crawlers allowed to retrieve the content according to robots.txt? Are services, the organisation and the people clearly named in the HTML? Is the schema markup consistent and connected via stable IDs? And, particularly importantly, does an additional plugin fail to generate duplicate meta tags, sitemaps or schema blocks? On a WordPress website, Yoast, the theme and custom structured data functions are often already at work; a further tool can help or it can output the same information a second time in a different way. More code does not automatically mean more visibility. The strategic side of this topic is covered in our [GEO framework for AI visibility and recommendations](https://4eck-media.de/en/blog/the-4eck-geo-framework-for-ai-visibility-ai-recommendations/). ![Cloudflare scan of the Bolzakademie website with level 5 agent-native and a score of 86](https://4eck-media.de/wp-content/uploads/2026/07/ki-optimierung-agent-native-website-bolzakademie-cloudflare.avif) ## AI bot logger: measuring who actually turns up If we want to know whether AI crawlers visit the website, we need data rather than gut feeling. An AI bot logger records accesses by known user agents. After the launch I check three things: is it actually running? Is the data plausible? And is it not slowing the site down? That comes with an honest caveat: a user agent is not a certified identity: it can be faked. The statistics are an instrument of observation, not a visitor list. And a warning about the new vanity metric: ten thousand bot requests are not a business success. A single qualified recommendation can be worth more. The aim is not to attract as many machines as possible, but to supply relevant systems with clear, up-to-date, quotable information. Data protection applies to the logs as well: the purpose, access rights and deletion period have to be settled. We do not store everything indefinitely just because it is technically possible. ## Tracking and cookies: consent has to work technically Tracking is only set up when it is planned for and legally clarified. Technologies that are not technically necessary generally require valid consent in Germany; the distinction is also explained by the [German Federal Commissioner for Data Protection and Freedom of Information](https://www.bfdi.bund.de/DE/Buerger/Inhalte/Telemedien/Cookies.html). What that means in practice: showing a banner and loading analytics straight away regardless is not consent, it is decoration. After the launch I therefore test three states: no decision, rejection, agreement. Before consent is given, scripts, requests and storage operations that require consent must not take place, and the same applies after a rejection, and I check that in the browser tools, not in the display of the consent plugin. Then there is the observation I make astonishingly often: a German cookie banner on an English or Polish page. Consent can only be informed if the user understands what they are deciding about. Categories, buttons and notices belong in the language of the page, a link to the cookie settings belongs on every language version, and rejecting must not be made artificially harder through colour or extra clicks. If tracking is running, it also has to be correct: do page views arrive in the right account? Are internal accesses filtered out? Do the events for forms and purchases work? An analytics ID embedded in the code is not yet a measurement concept. And this short example from practice shows what a badly implemented cookie banner can do to a live website, an SEO mistake that costs clicks and visibility: [Dieser SEO-Fehler kostet dich Klicks & Sichtbarkeit](https://www.youtube-nocookie.com/embed/Gj0skAo7-wI?feature=oembed) ## Executing redirects live: now the status codes count, not the plans The redirect map was prepared in part 1. Now it is executed and tested under real conditions. I check the status code and the target: as a rule, straight to the final HTTPS URL via a 301, without chains via HTTP, www and intermediate stops. Internal links are then switched over to the final URLs so that the website does not permanently navigate itself via redirects. The diagram in part 1 shows what chains and loops look like and why they do damage. [For moves with changed URLs, Google recommends](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=de) keeping redirects in place for at least a year, and in most projects there is no reason to remove them quickly after that. Old links live on in documents, emails and directories. Important: the map is not “done” once the launch is over. The real 404 requests of the first few weeks add to it: if a valuable old path is missing, the redirect is added and tested again. A relaunch rarely loses visibility because of one big mistake. Usually it is many small forgotten URLs. ## Spam protection: the honeypot first, heavier artillery only afterwards As soon as a form is public, bots will find it. That is not a question of whether, only of when. Our first layer of protection is a honeypot: a field invisible to humans that only bots fill in. For real users it creates zero additional work. After the launch I test both sides: a normal enquiry has to get through, a simulated bot pattern has to get stuck. Protection that is too aggressive is just as much a mistake as no protection at all: if client enquiries disappear, the website has missed its purpose, even if the spam folder stays exemplarily empty. I only use reCAPTCHA and similar services once the honeypot, timing checks and server-side rules are not enough. External captchas cost data protection clarity, accessibility and loading time, and their keys are tied to domains. This too is a live test, not a staging test. In the first few days we observe the real volume of spam and tune the level of protection to it. Security is not a switch, it is a balance between protection and usability. ## The first 24 hours: observe, prioritise, do not get frantic The immediate checklist is worked through after a few hours. After that the observation phase begins: error logs, 404 requests, form delivery, caching, availability. For shops there are also orders, payments and transaction emails; for portals, registration and password reset. And because findings are guaranteed to pile up in this phase, they need priorities, otherwise the list generates activity instead of quality. ![Overview of error priorities after the launch: P0 critical immediately, P1 high within 24 hours, P2 normal documented and planned](https://4eck-media.de/wp-content/uploads/2026/07/launch-priorities-p0-p1-p2.avif) Every finding needs usable evidence: URL, device or browser, steps to reproduce, expected and actual behaviour. “Form doesn’t work” is not a task. “Contact form on iPhone/Safari shows an endless loop after a valid submission; message is not delivered” is one. After a fix, the check is not carried out only by the person who implemented it, and I test the adjacent functions at the same time: a change to the consent manager can repair tracking and block a video along the way. Technical systems consist of relationships. After a week the real data comes in: Search Console, server logs, lawfully deployed analytics, support enquiries. I do not expect a perfect curve: rankings fluctuate during a migration, crawlers need time, users have to learn a new navigation. What matters are the patterns: are 404 errors rising sharply? Are form submissions collapsing? Is mobile LCP getting worse? Changes like these need a cause, not an excuse. ## The launch log: who, when, proved with what A few weeks later, someone is guaranteed to ask: was the form really tested after the launch? What PageSpeed values did we have? Were the redirects complete? Without a log, everyone answers from memory, and memories are remarkably flexible in day-to-day project work. Our launch log is deliberately simple: check point, responsible person, date and time, URL checked, result, evidence. Evidence means a screenshot with context, a tool report, a test email received. It has to match the claim. A green form message proves nothing about delivery; the message received does. Incidentally, the time is not pedantry: a PageSpeed test carried out before the consent manager was activated documents a different website from one carried out afterwards. We also document deliberate deviations: perhaps a page only reaches 92 instead of 95 points because of an indispensable booking service, in which case the log records the professional decision rather than simply “ignored”. The log protects the operation rather than the agency: if a problem turns up six months later, we can see the state of things at the time instead of searching in the fog. And the client receives a handover that a later service provider can work with. Good work should be capable of being handed over. Finally, a handover includes properly organised access: every person with only the rights they need, test accounts removed and an understandable briefing on the day-to-day tasks: maintaining content, preparing images, alt texts, finding form entries. The best technical foundation is damaged when an editor uploads 12-megabyte images because nobody has explained the difference to them. The client signs off on the professional side and approves the content. They are not responsible for finding our redirect chains. The client should be able to use the website, not finish testing the agency’s work. My standard after the launch - The live domain is treated as a new technical environment and checked in full. - No success message is a substitute for delivery, indexability or genuine function. - Scores help with the search, but they do not decide on quality by themselves. - Critical findings are given an owner, a deadline and an independent counter-check. - The client takes over a documented website, not an open building site. ## The complete after-live checklist at a glance As in part 1, the same applies: the overview is the condensed version of our internal list, copying is encouraged, and every point needs a name against it. A shop adds payment and order tests, a portal adds roles and permissions, an international website adds language switching and localised forms. | Check point | What exactly is checked | Consequence if it is missing | | --- | --- | --- | | Development site | Maintenance mode, password protection and public availability | Visitors see a barrier or the wrong version | | Indexing | WordPress reading setting, noindex, robots.txt, canonical, sitemap | Search engines cannot properly take in central pages | | Yoast | Titles, descriptions, canonicals, social preview, page types | Wrong or duplicate search signals | | Accessibility | Scanner, keyboard, focus, forms and consent layer | Users are excluded; legal and quality risks | | PageSpeed | Mobile, desktop, templates, LCP, INP, CLS | Slow usage and no buffer for later content | | Security headers | HSTS, CSP, referrer, permissions and frame rules | Avoidable attack surface or functions blocked by incorrect rules | | Favicon | Browser, direct file, light and dark interface | An unfinished brand presence | | Structured data | Schema.org, rich results, visible content, stable IDs | Contradictory machine signals or signals that cannot be processed | | Forms and email | Validation, sending, delivery, reply-to, languages | Enquiries are lost unnoticed | | Backups | Interval, external storage, retention and restore | An outage turns into data loss | | Seobility | Technology & meta, structure and content | Launch leftovers and crawl problems stay hidden | | Agent Ready | AI crawlers, content, schema, llms.txt and plugin conflicts | The website is harder for AI systems to classify | | AI bot logger | Function, plausibility, data protection and retention | No reliable data on bot accesses | | Tracking and cookies | Agreement, rejection, script blocking and language | Incorrect data and data protection risks | | Redirect map | 301 targets, chains, loops and real 404 requests | Lost visitors and search signals | | Spam protection | Honeypot, legitimate enquiries, captcha where needed | A flood of spam or blocked clients | ## Conclusion: after go-live it becomes clear whether the website is finished or merely online The launch itself takes longer than the DNS change. Switching off the development site, allowing indexing, accessibility and PageSpeed on the real domain, security headers, markup, emails, backups with a restore trial, crawling, AI readability, consent, redirects, spam protection, the log: only this overall picture turns a published website into a completed project. And the difference between quality and botched work is not the absence of errors. Websites are complex, devices are varied, external services change. The difference is accountability: searching systematically for likely errors, proving that critical functions work, being prepared for new findings. A poor handover sounds like this: “The site is online, get in touch if there’s anything.” A good one contains test results, open points, responsibilities and a contact person who can be reached. If you are planning a WordPress website, relaunching one or would like an independent review: more about our work can be found under [UI/UX design and web development](https://4eck-media.de/en/competencies/ui-ux-web-development-agency-4eck-media/), or you can [talk to us directly](https://4eck-media.de/en/contact/), gladly with your own checklist in hand. Specific questions are almost always a good sign. And if your freshly launched website is to become multilingual: our complete workflow article shows 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/), including the checks we use to verify every language. ## Frequently asked questions about the website launch checklist What do you need to check immediately after a website launch? Immediately after the launch, public availability, indexing, canonicals, the sitemap, Yoast, forms and email delivery, PageSpeed, accessibility, security headers, structured data, backups, redirects, tracking and spam protection all belong on the list. For shops and portals, business-critical special functions are added on top. Why is checking before go-live not enough? The production environment changes the domain, SSL, caching, email, external scripts, consent management and public availability. Many prepared settings can only be fully confirmed on the real domain. How quickly should the after-live check take place? Business-critical and basic technical checks are carried out immediately after the domain change. Logs, indexing, the development of 404s, real Core Web Vitals and usage data are then monitored further over days and weeks. Which PageSpeed value is good after the launch? At 4eck Media, 90 counts as the minimum value. Wherever possible we start with 94 to 95 points or more, so that later images, videos or marketing scripts do not immediately push the site out of the green zone. In addition, LCP, INP, CLS and several page types are assessed. Does every WordPress website need an external backup? Alongside the hosting provider’s backup, we recommend a separate copy held by the client or in an agreed cloud. What matters is a suitable interval, retention, data protection and a tested restore. A backup on the same web space does not protect against every kind of failure. What does Agent Ready mean for a website? An agent-ready website is technically accessible to AI crawlers and describes the organisation, people, services and expertise unambiguously in the visible HTML and in the structured markup. Plugins and llms.txt can support this, but they are no substitute for concrete, trustworthy content. Is a cookie banner enough for data protection compliant tracking? No. Scripts that require consent must remain technically blocked before agreement is given and after a rejection. The banner has to be understandable, accessible, revocable and, on multilingual websites, available in the right language. How long should redirects stay in place after a relaunch? Google recommends keeping redirects in place for as long as possible after a website move, and generally for at least a year. A longer period is often sensible, because old links from documents, directories and bookmarks continue to be used.