Our Own Website Was Invisible to Google. Here’s What Was Actually Wrong.

By Konstantinos Karamatzianis · Co-Founder, Dabster Labs

Published 7 July 2026

We build systems that AI assistants and search engines are supposed to find and recommend. So it was a little humbling to discover that our own website, freshly rebuilt, full of good content, was completely invisible to Google. Not ranking badly. Invisible. Zero pages indexed.

Here’s what was actually wrong, in the order we found it, because the mistakes were not the ones you’d expect from a “how to get indexed” checklist, and the real culprits are exactly the ones those checklists never mention.

The content was fine. The door was locked.

The instinct when a site isn’t ranking is to reach for content and keywords. That instinct was useless here, because the problem was one level down: an automated crawler literally could not fetch the pages. Google wasn’t ignoring our content, it had never been allowed to read it.

The first cause was almost embarrassing. An “under construction” mode was still switched on from an earlier stage of the rebuild. To a human clicking around it looked mostly fine, but to Google the site served a “we’ll be back shortly” placeholder, so the only thing Google had ever cached was a holding page. Every case study, every article, invisible, because the crawler was being handed a doormat instead of a house.

The bug the checklists never mention: server-level blocking

Turning off the under-construction mode should have fixed it. It didn’t. The site was still refusing automated visitors, and this is the part almost no “SEO tips” article covers, because it isn’t really an SEO problem at all.

The block was happening at the server level, before a request ever reached the site’s own rules. A security layer, the kind that’s genuinely useful against malicious bots, was treating every non-human visitor as a threat, including the search engine crawlers we desperately wanted to let in. Our own robots.txt file said “everyone welcome.” It didn’t matter, because requests were being turned away at the door before they ever got far enough to read it. That’s the trap: you can spend days perfecting a file that the thing blocking you never even looks at.

Proving it was fixed, the only test that counts

Once we’d cleared the real blockers, we didn’t want to assume Google could get in. Assuming is what got us here. So we verified it directly, using Google’s own inspection tool to send the real crawler at the live page and report back exactly what it saw. The answer we needed was unambiguous: crawl allowed, page fetched successfully, indexing allowed. Not “should work”, does work, confirmed by the one visitor whose opinion actually matters.

Then, and only then, does the ordinary advice apply: submit a sitemap, request indexing for the key pages, and let the priority queue do its job. All the sitemap-and-keywords guidance in the world is wasted effort until the crawler can physically reach your pages. Order matters, and almost everyone does it backwards.

The takeaway

If a site genuinely isn’t getting indexed, the odds are it’s not a content problem, it’s an access problem, and access problems hide in the least glamorous places: a forgotten maintenance toggle, an over-zealous security layer, a single misconfigured line. The fix isn’t better keywords. It’s making certain a crawler can actually get in, and then proving it rather than hoping. We build this kind of technical visibility into the systems we deliver, because content nobody can reach is the most expensive kind of content there is, all of the cost, none of the benefit.

If your site isn’t showing up and you can’t work out why, that invisible access problem is exactly the sort of thing worth a second pair of eyes. Book a free discovery call and we’ll help you find where the door is locked.