Checks eight sites three times a day to see whether search engines can read them

Background

A site opening is a different thing from a search engine being able to read it.

You type an address and the page loads — yet the file that tells the search engine what it may read (robots.txt) has no sitemap written in it, or the marker saying 「this is the real address of this post」 points at an address that automatically forwards somewhere else, or the visitor-count code you pasted in never actually arrives anywhere. None of this gives itself away on screen.

The problem we defined

A site can be opening normally while remaining invisible to search engines.

• Numbers do not arrive at the visitor-count tool you pasted in. The admin screen says 「connected」, and the code is embedded in the page as is. Yet not a single visit is recorded
• No error appears. So it is discovered later. The page opens fine, and no red mark appears anywhere the person in charge can see
• When work is handed over, there is no way to check whether it was applied. A reply of 「done」 and the state that was actually applied are different things, and no screen distinguishes the two

We find such spots and turn them into a check that re-verifies, three times a day, not whether something is attached but whether it actually arrives.

What we built

• Three times a day, 07:50 · 12:50 · 18:50 — it opens the eight sites in turn
• Up to twelve items per site — whether the home page loads, whether multiple addresses merge into one, whether the 「this is the real address of this post」 marker points at the right place, whether the search-engine guidance file can be read, whether the site’s table of contents is written in that file, whether the table of contents is structured correctly, whether an ownership-verification mark is present, whether information in a format search engines recognize is attached, whether there is a description, and whether the visitor count actually arrives
• Our checks leave nothing on your site — they only read and never modify. If a check created fake visits, your visitor numbers would be polluted
• Alerts that fire every day end up seen by nobody — so we split the judged items from the recorded items. Each site has its own circumstances, and there are cases where 「this item is not a problem on this site」; keep those red and real problems become invisible too. We do not mark them as passed either — we demote them to records and keep who confirmed them and when alongside
• It answers only what it can answer — what this tool answers is 「is it in a state search engines can read」. Search ranking and visitor counts are different questions, and the tool does not pretend to know those too
• It reports only what changed from yesterday — twelve items at eight sites three times a day piles up results fast. Send everything and nobody reads it; unread is the same as nonexistent. Only the changed lines come through
• 78 automated tests rerun on every change — the check tool never turns on a green light while silently broken

We record 「pass」 and 「could not confirm」 as different values

Any company running several sites will have lived through this.

• A site that does not count visitors at all shows up as 「normal」. With a single green light on the table, it is indistinguishable from 「visitors are being counted properly」. We carry 「did the check pass」 and 「are visitors actually being counted」 as separate values, and what could not be confirmed is written as 「unconfirmed」, not 0. So you get an answer to 「can the visitor count of this site be trusted right now」.
• There is a kind that works fine in development and only fails on the actual server. No matter how often it is run on a development computer, the same thing does not happen — but on the actual server, a perfectly alive site shows up as 「connection failed」, and the remaining eleven items of that site are skipped entirely. We had that case handled directly, and automated tests guard it so it is not removed later. So you can take 「the check turned on a red light」 at face value — real failures and check-tool malfunctions never mix

Why three times a day

With once a day, the day that single run is missed becomes a total blank. Even the checking server stops sometimes. On a day when the morning six hours were actually missed, the midday run covered them — even on the day the check was missed, that day’s state remained.

What you touch is confirmed right away

Adding an ownership-verification mark to one site, the next check caught the change outright (2026-08-09). Even if the person who did the work says nothing, that one line appears under 「changed items」 in the next run. Nobody has to go around checking 「you say it’s done — was it actually applied」.

Result

The required-item failures that numbered 24 on August 12, 2026, came down to 16 in the 07:50 check on August 23. 16 items still remain. Because this number is produced directly by the tool, not tallied by a person, both the claim that it went down and the claim that it remains come from the same place.

So for you

Whether you run eight sites or one, we build the same structure. You get an answer, refreshed three times a day, to 「is my site in a state where search can find it right now」. Whether work entrusted to an agency was actually applied, whether the visitor-count tool you pasted in is actually receiving visits, what changed between yesterday and today — things that today only a person in charge can find out by opening each one. The remaining failure count stays on the screen, so what to fix next remains as a list.

Other work made the same way is gathered under Web data collection.

Other systems we use to run our own company are gathered under In-house operations automation.