A subdomain finder helps you discover names beneath a domain, such as shop.example.com or help.example.com. Screpy searches public certificate records, removes repeated names and returns a list you can filter, copy or export. It also keeps wildcard patterns separate so they are not mistaken for individual websites.
Use the result to start an inventory of a website's public footprint. A certificate record is evidence that a name appeared in that record; it does not confirm that the name currently resolves, serves a page or appears in Google. Those questions need separate checks.
Find subdomains from certificate records
Enter a domain such as example.com and select Find subdomains. You can also paste an HTTP or HTTPS URL; the lookup uses its hostname. A page path does not narrow the certificate search to that page. If you enter shop.example.com, the search stays beneath that hostname instead of silently changing to example.com.
The lookup reads names from the returned certificates' Common Name and Subject Alternative Name fields. Matching is based on DNS labels: help.example.com belongs beneath example.com, while notexample.com does not. Uppercase variants and repeated occurrences are combined into a single row. The parent domain itself is not counted as a subdomain.
Certificate Transparency logs record certificates and precertificates in public, append-only logs. Searching that history can reveal names that ordinary links on a homepage do not expose. This tool reads the certificate search results; it does not crawl the discovered hosts, guess names or attempt to log in to them.
Read names, wildcards and certificate dates
The result separates concrete subdomain names from wildcard patterns. This fictional example shows the distinction; these rows are not a captured lookup.
| Returned name | Type | What you can conclude |
|---|---|---|
shop.example.com |
Hostname | This exact name appears in a retained certificate record. |
help.example.com |
Hostname | This is another concrete name to compare with your inventory. |
*.example.com |
Wildcard | The certificate names a pattern; it does not enumerate the hosts covered by it. |
A wildcard does not establish that shop, mail or any other particular label exists. Screpy therefore reports a wildcard count separately from the concrete subdomain count. Nested names, such as api.shop.example.com, remain visible when the returned records name them explicitly.
Record count means the number of distinct retained certificate record IDs that mention a name. A host can have many records because certificates are renewed or logged in different forms. Ten records for one name still produce one hostname row; the count is not traffic, ten websites or a measure of SEO importance.
The date columns show the earliest certificate validity start and latest certificate validity end among the retained records for that name. They are not the hostname's creation date, the dates it was first or last online, or a current certificate inspection. A future expiry does not prove that the host still exists or serves that certificate. A missing date stays unavailable rather than being estimated.
Understand the limits of passive discovery
No certificate-based subdomain finder can promise a complete, current domain inventory. A name can be absent because it has never appeared individually in the searched records, uses a private certificate, is covered only by a wildcard, or has not yet reached the search service's dataset. Conversely, a returned name may belong to a retired service whose certificate remains in the history.
This lookup does not resolve discovered names, inspect their HTTP responses, check Google indexing or establish present-day ownership. Labels such as dev and admin are names, not proof of an exposed development server or a vulnerability. Keep any conclusions separate from what the record actually says.
Screpy processes up to 5,000 returned certificate records and retains up to 2,000 unique names, including wildcard patterns. A limited report says so explicitly. A successfully processed response is still limited to the records the source returned.
An empty successful lookup means no matching subdomain names were extracted from those records. A timeout or unavailable source means the lookup could not be completed. Retry a failed request later; do not interpret an error as confirmation that the domain has no subdomains.
Turn discovered names into an SEO audit
Start by comparing the list with the hosts you already manage. Look for a separate shop, help center, regional site or old campaign that is missing from your working inventory. Treat the name as a lead to verify, not as proof of what the service does. A useful inventory records the host, its owner, its intended purpose and the next check it needs.
For hosts you manage, follow a short sequence:
- Check the response. Use Bulk HTTP Status Checker on the specific HTTP or HTTPS URLs you intend to audit. It distinguishes a working response, redirect and error; the certificate lookup does not.
- Confirm the intended search visibility. A public article and a private customer portal have different requirements. Use Noindex Checker to inspect relevant directives rather than assuming that every discovered host should rank.
- Review duplicate destinations. If a public host serves content available elsewhere, Canonical Tag Checker can inspect the page's declared canonical. A name alone tells you nothing about duplication or Google's selected canonical.
- Check the right sitemap. Use Sitemap Checker for the site or sitemap you actually want to inspect. The subdomain list is not a list of every page, and sitemap inclusion does not guarantee indexing.
Keep a retired name in the inventory until you have confirmed its current DNS and service configuration through the systems you control. Finding it in certificate history is a reason to investigate, not an instruction to delete it or an explanation for a ranking change.
Export the list and preserve its context
Use the name filter to focus on a host or part of a name, and the type selector to separate concrete hostnames from wildcard patterns. The table shows up to 50 rows per page. Copy and CSV export use all names matching the current filters, not just the visible page. Keep wildcard rows identified as patterns if you include them in an inventory.
Download JSON when you need the complete returned report, including the retained certificate records behind the names. The JSON includes the searched domain, lookup time, coverage limits and flags showing that DNS and HTTP were not checked. These fields help another person understand what the exported list represents.
Save the lookup context alongside any conclusions. A partial report, an old certificate and a live response are different kinds of evidence. Repeating the lookup can produce different results as the source changes; the export is a snapshot of that response, not continuous monitoring.