What is a web property graph?
Seeing a domain as a connected set of observations — hosts, certificates, records and dependencies — rather than as a single page.
A web property is not a page. It is a domain plus everything measurably attached to it: the hosts it resolves to, the certificate covering those hosts, the mail infrastructure, the crawler rules, the third parties each page pulls in. Treating it as a graph rather than a URL is what lets you reason about it as a system.
Why "check my website" is the wrong unit
People ask for a website to be checked and mean a page. But almost every consequential fault lives in the relationships between things rather than in any one of them.
- The certificate covers
wwwbut not the apex — a fault in the relationship between a name and a certificate. - The canonical tag points at a host that redirects back — a fault between two pages.
- The MX records point at a provider that was decommissioned — a fault between a domain and a service.
- A third-party script on the checkout page is absent from the homepage — a fault that only exists on one node.
None of these is visible in a single page fetch, because none of them lives in a single page.
The nodes
| Node | Attached observations |
|---|---|
| Domain | NS delegation, CAA, DNSSEC presence, registrar-level posture |
| Host (apex, www, subdomains) | A/AAAA records, redirect behaviour, response headers |
| Certificate | Issuer, validity window, covered names, chain completeness |
| Mail path | MX targets, SPF, DMARC policy, DKIM presence |
| Page | Metadata, headings, structured data, indexability directives |
| Third party | Origin, resource type, whether it executes, consent gating |
| Crawler policy | robots.txt groups, resolved per bot and per path |
The edges are where the faults are
Each of these is a relationship, and each is a common real-world failure:
- Host → certificate. Is this hostname actually in the SAN list? The apex-versus-wildcard gap is a perennial.
- Page → canonical target. Does the canonical resolve directly, or through a redirect, or to a different host entirely?
- Page → third party. Which origins does this specific page contact, and do they execute?
- Domain → mail provider. Do the MX targets resolve, and does SPF authorise the service that actually sends?
- Crawler → path. Which rule group applies to this bot, and what does it permit here?
- Host → host. Do apex and www agree on headers, certificate coverage and canonical direction?
Why this framing helps an agent
An agent given a flat list of findings has to reconstruct the structure before it can reason about causes. Given the graph, it can answer questions a flat list cannot:
- "Which pages load this third party?" — rather than "does the site use analytics".
- "Is every host I serve covered by a valid certificate?" — rather than "is the certificate valid".
- "Does anything link to a page that noindexes itself?" — a contradiction only visible across an edge.
- "Did this regression affect one host or all of them?" — a question about scope.
These are the questions that produce root causes instead of symptom lists.
Building the picture
- Enumerate hosts: apex, www, and any subdomains you actually serve.
- Measure each independently — they are separate nodes and will differ.
- Map the certificate against every host it is supposed to cover.
- Follow redirects and record where each host actually terminates.
- Inventory third parties per page type, not once for the site.
- Resolve crawler rules per bot and per section, rather than reading the file as a whole.
Step two is the one most audits skip, and it is where a surprising share of real faults are found.
What our audit reports about this
Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.
- The final host after redirects, reported explicitly, so results are attributed to the host actually measured.
- Certificate coverage evaluated against the hostname requested, including the apex-versus-wildcard case.
- Per-page third-party inventories rather than a single site-wide list.
- Crawler rules resolved per bot and per path, naming the group and line responsible.
For agents and scripts, the same measurement is at
/api/v1/summary?url=yoursite.com —
see the API documentation.
Related questions
Should I audit www and the apex separately?
Yes. They are different hosts and frequently differ in headers, certificate coverage and redirect behaviour. Auditing only the one you type in is how apex-only certificate gaps survive for years.
Why does my audit report a different host than I asked for?
Because it followed your redirects and is reporting where it ended up, which is the host that actually serves visitors. It is stated explicitly so results and stored history are never filed under a host you did not expect.
Do subdomains need their own audits?
Any subdomain you serve to the public, yes. They typically have separate configuration, and it is common for a marketing subdomain on a different platform to be considerably worse configured than the main site.
Is this just a sitemap?
No. A sitemap is a list of pages. This is the set of infrastructure objects attached to a domain and the relationships between them — certificates, mail paths, hosts, crawler policy — most of which no sitemap describes.
Read next
How do I find every page on a website?
Enumerating a site's URLs from sitemaps, crawling and internal links — and why no method gives you a complete list.
ReadWhat is web provenance and why does it matter?
Knowing where a claim about a website came from — and why "measured", "derived" and "inferred" must never be presented as the same thing.
ReadHow do I read a TLS certificate?
What each field in a certificate means, which ones actually matter, and how to inspect any site's certificate in one command.
ReadWhat do my DNS records actually say?
Reading your own DNS from first principles — which records exist, what each one decides, and the four commands that show you all of them.
Read