What does a website check really tell you?

The same eight addresses, four days apart.

On 3 October 2026, 8 of eight selected pages could be assessed. On 7 October, 7 could be assessed. The fixed selection includes our homepage, website builder, managed service, Growth OS route, AI services, projects, checker and knowledge hub. This is not a sample of Dutch businesses.

The Growth OS address could not be assessed under the second run’s rules. The collector refuses redirects, so this does not by itself mean the website is broken. The address stays in the sample as unknown, not as a failed or successful check.

What changed in the checks?

Among the 7 pages assessed on both dates, we found 0 changes in the recorded check statuses. That does not mean the words or design stayed the same.

The two observations do not measure visitors, search positions, outside links, AI mentions, enquiries or income. A readable title or page-information block is not proof that the content is useful or that Google shows it.

How to repeat the measurement.

The check reads each public page file without signing in or running the page’s scripts. It checks the same addresses one after another, with 250 milliseconds between requests. It reads the access-rules file, robots.txt, and the page list once. It follows no redirects, submits no forms and keeps failed requests as unknown.

Page requests have a 1.2 MB size limit and seven-second timeout; robots.txt has a 256 kB limit and four-second timeout. Title lengths of 25–65 characters and description lengths of 100–165 are checker settings, not Google requirements.

The selected addresses and assessment rules are unchanged. The software now records extra details about when and how a report was made, so its identifying check code has changed. We compare only the existing observations. Each file retains the collection times, method version and software check code so differences can be checked.