Download the PHP package webagentur-yahya/golive-check without Composer

Go-Live Check for TYPO3

The classic mistakes made when a website goes live, checked against your site — with the value that was actually found, and what to do about it.

A robots.txt taken along from staging hides the entire site. Nothing breaks, the pages look right, and the mistake surfaces weeks later when someone asks why the site is not in Google. The sitemap line in robots.txt is the only place in a TYPO3 configuration where the domain is spelled out, so it is the only one that does not travel along when the site moves. A 404 handler pointing at a hidden page turns every unknown address into a server error.

This extension looks for those, and for about two dozen more.

What it checks

Indexing and sitemap — robots.txt is delivered, does not lock search engines out, and names the right sitemap · sitemap.xml really answers with XML and lists this domain · pages excluded from search · base address is the live domain · website title is not the template's.

TYPO3 configuration — production context · 404 handler and whether its target page exists and is published · mail actually leaves the server and has a real sender · build-time extensions still active · scheduler set up and actually running.

Security — debug switches · host header restriction · administrator accounts still using a build-time password · document root exposing .env and the database credentials · http redirecting to https · TLS certificate validity and remaining lifetime · the four protective response headers.

Legal — imprint and privacy page exist and are published.

Content — filler text on visible pages · missing meta descriptions.

On top of that, twelve points only a human can confirm — backup restore actually tested, redirects from the previous site imported, nothing tracking before consent — recorded with the user who confirmed them and when, so the report doubles as a handover protocol.

What it does about them

Every finding names the value it found, says in one sentence why it matters, and links to the place where it is fixed. Where the correct answer follows necessarily from the site configuration — the two robots.txt cases — there is a button that applies it.

Where it does not, there is no button. A control that quietly writes a guess into a configuration is worse than none, because afterwards nobody looks again.

Checks that cannot reach their answer — no loopback to the live URL, extension not installed, relative base — report as not verifiable rather than passing. A false green replaces the very check it pretends to be.

The report prints. Print / save as PDF produces a handover document with site, domain, date, author and TYPO3 version.

Installation

Then open Site Management → Go-Live Check in the backend. Administrator access is required.

Adding your own checks

A check is one class implementing CheckInterface. It is collected automatically — the DI container tags everything implementing the interface, so no registration list needs editing:

Your extension needs the same _instanceof block in its Services.yaml, and the texts under check.myCheck.title, .why, .fail, .solution and .ok in a language file registered via $GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride'], or simply returned as literal strings.

Implement FixableCheckInterface as well if — and only if — the correct value can be derived without guessing.

Documentation

Documentation/ holds the manual: every check with its severity and what makes it fail, what "not verifiable" means and what causes it, the manual checklist, and the API for your own checks. It is written for the TYPO3 render pipeline and can be built locally with

Licence

GPL-2.0-or-later. Built by Webagentur Yahya.