How Attackers Find Your Brand-New Website Within Hours (and Why Hiding Won’t Save It)

Through Certificate Transparency logs. When your site gets the HTTPS certificate it needs to serve traffic securely, that certificate, including the hostname it covers, is recorded in public, append-only logs by design, so the certificate system can be audited for fraudulent issuance. Anyone can read those logs, and there are real-time feeds of every certificate as it is issued. Attackers subscribe to that feed, so instead of guessing at domains they get a live list of newly created sites and subdomains to probe, often within minutes of the certificate being issued. Crucially, this requires no links to your site, no search indexing, and no interaction with your server at all; the reconnaissance is entirely passive because it reads a public third-party archive. That is why having no inbound links or not submitting your site to search engines does nothing to hide it: the certificate already announced the hostname to everyone watching.

No, it is a security feature, and an important one, which is why the honest framing matters. Certificate Transparency exists so that the issuance of website certificates is transparent and verifiable: certificates are recorded in publicly verifiable, append-only, tamper-proof logs, which lets anyone detect certificates that were issued fraudulently or by mistake. Before it existed, a bad actor who tricked a certificate authority could impersonate a site with far less chance of being caught. The system makes the whole web safer. The side effect that matters for site owners is that it also removes the illusion of obscurity, because every new hostname becomes publicly visible at issuance. That is not a flaw in the system; it is the transparency working as intended. The right response is not to avoid Certificate Transparency, which is not really possible for a normal HTTPS site anyway, but to stop treating a new or unlinked site as hidden and to protect it as though it is always visible, because it is.

No, neither one hides your site from an attacker. A robots.txt file is only a polite request to well-behaved search crawlers about what to index; it has no power to stop anyone, and attackers ignore it entirely, sometimes even reading it for hints about paths you would rather keep quiet. Not being indexed by Google is similarly irrelevant, because search indexing and certificate transparency are unrelated systems: your site can be absent from every search engine and still be sitting in the public certificate logs from the moment it got HTTPS. People conflate not appearing in Google with not being findable, but attackers do not find sites by searching Google; they find them by reading certificate logs, scanning IP ranges, and monitoring real-time certificate feeds. The only reliable conclusion is to assume your site is discoverable the instant it exists, and to protect it accordingly rather than counting on any form of obscurity.

Fast enough that you should assume there is no grace period. Because Certificate Transparency publishes your hostname the moment your certificate is issued, and attackers monitor those logs in real time, the window between going live and being probed is effectively zero, often minutes to hours. In our own experience rebuilding a site and giving it a fresh certificate, a real attacker found the new address through the public logs within days and immediately ran an automated playbook against it. That speed is possible because the probing is automated at massive scale, not done by hand: across the web, the majority of traffic is now bots, and 94% of login attempts come from automated tools constantly testing sites the same way. The practical takeaway is that you cannot count on finishing your security work quietly after launch, because the launch itself, in the form of the certificate, is the announcement. Harden before you go live, and assume immediate discovery.

By making discovery lead nowhere useful, which comes down to two things that do not depend on being unknown: keep nothing exposed to exploit, and filter hostile traffic before it reaches your site. Minimizing the surface means no exposed admin login, no unnecessary runtime, and no vulnerable add-ons, so the automated probes that find you have nothing to work with. Filtering in front means a layer that inspects and blocks the reconnaissance and attacks before they land on your origin. For a mostly static site, edge hosting delivers both: the site is served as static files with no login, no PHP, and no plugins, and filtering sits in front, so an attacker who finds your hostname in a certificate log, as they will, arrives at a site that gives them nothing. It is not a promise of immunity, because your domain, DNS, and management accounts still need to be secured properly. But it changes the outcome of the discovery that certificate transparency guarantees, from a risk into a non-event.

Yes, and you should, because the same logs that expose you are a genuine early-warning system. Every certificate issued for your domain, or for a look-alike designed to impersonate it, appears in the public logs, so monitoring them lets you catch abuse you would otherwise miss. The most valuable use for a small business is spotting phishing domains early: attackers frequently register look-alike domains that mimic a real brand, and the certificates for those domains show up in the same feed, so an alert can warn you before a phishing campaign using your name goes out. Monitoring also surfaces unexpected certificates for your own domain, which can indicate a misconfiguration or a compromise, and unfamiliar subdomains you did not create. There are free services that watch Certificate Transparency logs and notify you when a certificate matching your domain or a close variant is issued, and setting one up is a low-effort, high-value defensive step. It turns the transparency of the system, which removes your obscurity, into a tool that works for you.