A 30-minute dig for a competitor's subdomains

Your competitor cannot hide their subdomains. Not because someone leaked them, but because certificate transparency is how the modern web works: every TLS certificate a public certificate authority issues gets written to an append-only public log, and those logs are searchable by anyone. staging. shows up. demo-partner-portal. shows up. The one for a product line that doesn't have a marketing page yet shows up too.

This is a manual dig, not a monitor. You do it when you're onboarding a new competitor, when something feels off about their positioning, or once a quarter as a scheduled sweep. Half an hour, start to finish. Here's the sequence.

Step 1 — Pull the raw list, don't guess at it

Guessing subdomain names is a waste of an afternoon. Start from the log.

• Search a certificate transparency aggregator (crt.sh is the common one) for %.competitor.com. You'll get every certificate issued for that domain and its subdomains, with issue dates.
• Export or copy the common name and SAN columns. A mid-size SaaS company will return anywhere from 20 to 400 unique hostnames.
• Deduplicate. Wildcard certs (*.competitor.com) tell you nothing on their own — set them aside.
• Keep the issue dates. They're the most valuable column and the one people throw away first.

Do not skip to browsing. The list is the artifact; everything after this is filtering.

Step 2 — Sort into four buckets

Most of what you pulled is noise. Sort ruthlessly, in this order:

• Infrastructure — mail., mx1., vpn., cdn., smtp.. Discard. These tell you about their vendors at best, and there are better surfaces for that.
• Known products — subdomains that map to something already on their website. Discard, but note the issue date if it's recent; a re-issued cert on a live product sometimes means a platform migration.
• Environments — staging., qa., dev., preview-*. Interesting only in aggregate. A jump from three to fifteen environment subdomains in a quarter says the engineering org grew or the release process changed.
• Unexplained — a name you cannot map to anything public. This is the bucket. Usually it's two to five entries.

The unexplained bucket is where the next thirty minutes go.

Step 3 — Check what actually responds

A certificate proves someone provisioned a hostname. It does not prove anything is running there.

• Resolve each unexplained hostname and note the HTTP status. A 200 is a live thing. A 401 or 403 is a live thing behind auth — arguably more interesting. NXDOMAIN means the cert outlived the host, which happens constantly.
• Look at what a live host serves. A login screen with a product name on it is a name you now know. A default cloud landing page is nothing.
• Note the issue date against the response. A hostname provisioned four months ago that now returns a branded login page is a project that survived a quarter.

Be a normal visitor: load the page, read what's public, leave. Don't probe, don't try credentials, don't poke at anything behind the auth wall. The signal is in the existence and the name, not in getting inside.

Step 4 — Corroborate against surfaces that talk

A subdomain on its own is a hypothesis. Two surfaces agreeing is a finding.

• Sitemap and robots.txt — a Disallow: entry matching your unexplained hostname is confirmation. This works both directions; see what a competitor's sitemap leaks and what robots.txt quietly gives away.
• Job postings — a role mentioning the same product noun as the subdomain dates the project better than the cert does.
• Docs and API references — unlinked doc sections often ship before the marketing page.
• Support and community threads — beta customers talk. A product name that appears in both a cert log and a forum post is real.

If nothing corroborates, the finding stays a hypothesis. Write it down as one.

Step 5 — Write it down with a date and a falsifier

Two lines per finding, in whatever your team already reads:

• What you saw, verbatim: hostname, cert issue date, HTTP response, date you checked.
• What would change your mind: "if this still 404s in November, it was abandoned."

The date stamp matters more than the prose. When someone asks in six weeks whether this was new, you want an answer, not a memory — the same discipline as timestamping any competitor change.

Step 6 — Decide what you're actually going to watch

Here's the honest limit of this playbook: a certificate dig is a snapshot. It tells you what exists on the day you looked, and it goes stale immediately. Re-running it manually every week is exactly the kind of task that gets dropped by week three — the failure mode behind most stealth-competitor tracking.

So split the work. The cert dig stays manual and quarterly. The surfaces that corroborate it — pricing, docs, sitemap, changelog, marketing pages — are where continuous monitoring belongs, and that's what Seeto is for: it watches those public surfaces and surfaces each change as a discrete, timestamped event, so when the product behind that unexplained subdomain finally gets a page, you see the diff instead of rediscovering it. Seeto doesn't crawl certificate logs, and it won't do the sorting in Step 2 for you. That part is your thirty minutes.

Do the dig this week on one competitor. If the unexplained bucket comes back empty, that's a finding too — it usually means they ship on a single domain, and your monitoring should be aimed somewhere else entirely.