Website Analyzer

Enter any URL and get its full technical profile — headers, TLS, DNS, SEO, tech stack and what's broken.

Website Analyzer takes a single URL and returns everything a developer normally gathers from five different tabs: the technology stack behind the page, every HTTP and security header, the TLS certificate and when it expires, DNS and email-authentication records, who the domain is registered to, the full on-page SEO picture, and a prioritised list of what is actually wrong. One request, one report, no account.

Try:

How Website Analyzer works

The analysis begins with a single ordinary GET request to your URL, following redirects manually so the full chain is visible in the report — that alone catches misconfigured http → https → www hops that quietly cost a redirect on every visit. From the response we read the status, the timing to first byte, whether the body arrived compressed, and every header the server chose to send. Six of those headers form the security grade: HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy. The grade is weighted rather than a simple count, and it knows that a CSP with frame-ancestors makes X-Frame-Options redundant, so a modern configuration is not penalised for omitting a legacy header.

While the page is being parsed, four independent probes run in parallel. A TLS handshake pulls the live certificate — issuer, the names it covers, the negotiated protocol and cipher, and the exact number of days until it expires. DNS lookups collect A, AAAA, MX, NS, CNAME and TXT records, and pull SPF and DMARC specifically, because a domain that accepts mail without either is trivially spoofable and almost nobody checks. An RDAP query — the modern replacement for WHOIS, served by the registries themselves — returns the registrar, the registration and expiry dates, and the domain's age. Finally robots.txt and the XML sitemap are fetched to establish what crawlers are allowed to see.

The HTML itself is parsed for the things that decide how a page performs in search: title and meta description with their lengths measured against what Google actually displays, canonical URL, robots directives, heading structure, word count, hreflang alternates, JSON-LD structured data types, Open Graph and Twitter card tags, internal versus external links, and images missing alt text or explicit dimensions. Technology detection runs a set of signatures against the markup, headers and cookies to identify frameworks, CMSes, analytics, CDNs and server software.

API discovery works from three sources, and the report labels which one every entry came from, because they are not equally trustworthy. A published OpenAPI or Swagger spec is authoritative: when a site serves one at a conventional framework path, you get the complete endpoint list along with the descriptions its own developers wrote, which is the only place "what is this API for" is documented rather than guessed. A deep scan is the second source — it opens the page in a real browser and records every request, so an endpoint listed there was genuinely called, though its purpose is still inferred from the URL. The third and weakest source is a scan of the site's JavaScript bundles for API-shaped string literals; those prove the code mentions a path, nothing more. Third-party services are named outright from a known-domain list, so a call to Stripe is reported as payments and a call to Sentry as error tracking, with no guesswork involved.

Everything then feeds one synthesis step that produces the findings list. That list is the point of the tool: raw header dumps are easy to generate and hard to act on, so each finding names the problem, says why it matters, and carries a severity so you know what to fix first. Only the target site is contacted — we do not scan ports, enumerate hidden endpoints, fuzz parameters, follow links, or crawl beyond the single page you named.

How to use Website Analyzer

1

Paste a URL

Type a domain like example.com or a full https:// address. You can drop the scheme — we add https:// and follow any redirect to the canonical address.

2

Run the analysis

We fetch the page once and run the DNS, certificate, registry and robots.txt probes in parallel. Most sites finish in two to four seconds.

3

Read the findings

Start with the findings list — it is sorted by severity, not by category. Then use the detail cards below it, or export the whole report as JSON.

Frequently Asked Questions

What exactly does the website analyzer check?
+
Response status and redirect chain, timing and compression, six security headers with a weighted grade, the live TLS certificate and its expiry, DNS records including SPF and DMARC, domain registration via RDAP, robots.txt and XML sitemap, full on-page SEO and structured data, technology stack, and any contact or social links published on the page.
Can I analyze a site I do not own?
+
Yes. Everything the tool reads is information the site already publishes to every visitor — its own HTML, its response headers, its certificate, and public DNS and registry records. No scanning, probing or authentication is involved.
Why does it say my page has no content when it clearly does?
+
Your site is probably a single-page app that renders in JavaScript. We report the HTML the server actually returns, which is what search engines and AI crawlers see first. If that HTML is an empty shell, the report says so explicitly — and that gap is itself the most useful finding on the page.
How accurate is the technology detection?
+
It matches published signatures in the markup, headers and cookies, so what it reports is reliable, but absence is not proof. A site behind a CDN that strips headers, or one that has renamed its asset paths, can hide a framework the detector would otherwise catch.
What is RDAP and why not WHOIS?
+
RDAP is the IETF-standard replacement for WHOIS. Registries serve it as structured JSON over HTTPS rather than unparsed text, so registrar, dates and status come back reliably. Some registries — several country-code ones in particular — still publish little or nothing, and the report says so instead of guessing.
Is the analysis stored anywhere?
+
No. The report is generated on request and returned straight to your browser. Nothing is written to disk and no report is retained after the response. Use the Download button if you want to keep a copy.
Can I analyze a page on localhost or an internal server?
+
No. Requests to private, loopback and link-local addresses are refused by design — a public tool that fetched internal addresses could be used to reach servers that are not meant to be publicly reachable. Analyze a publicly resolvable URL instead.
What does the health score mean?
+
It starts at 100 and subtracts a weighted penalty for each finding, so a critical issue costs far more than a cosmetic one. It is a quick way to compare pages or track a site over time, not an official metric — read the findings list for anything that matters.
How do I see which APIs a website uses?
+
Run the analysis, then click "Run deep scan". That opens the page in a real browser and records every network request it makes, so you see each API endpoint the site actually calls, its method and status, how many times it was hit, and which third-party services are involved. If the site also publishes an OpenAPI or Swagger spec, the fast scan finds that on its own and lists every documented endpoint with the developers' own descriptions.
Why does the deep scan take longer than the main analysis?
+
The fast analysis is a single HTTP request plus some DNS and certificate lookups, which takes two to four seconds. The deep scan launches a headless browser, loads the page fully, waits for late-firing requests and scrolls to trigger lazy-loaded data — that is genuinely a ten-to-twenty-second job. It is a separate button so you only pay for it when you want it.
Are the API purposes accurate?
+
It depends on the source, and the report tells you which one applies. "Documented" comes from the site's own API spec and is accurate. "Known" means the request went to a service we recognise, like Stripe or Sentry, and is reliable. "Inferred" is a guess from the URL path and HTTP method — usually right, occasionally wrong, and never something to depend on without checking. "Referenced" merely means the string appeared in the site's JavaScript.
Can I get a cURL command for the APIs it finds?
+
Yes. After a deep scan, click any endpoint to expand it — you get a ready-to-run cURL command with the method, full URL, query parameters, request body and the headers that make the call work, plus a copy button. It is the same idea as "Copy as cURL" in Chrome DevTools, except you get it for a site you have not opened yourself.
What data does each API return?
+
Expanding an endpoint also shows the structure of its response: every field name, its type, and how many items are in each array, nested several levels deep. We deliberately show names and types only, never the values — the same scan that reads a public scoreboard could just as easily read someone's profile or order history, so no response content is ever captured or returned.
Does it find hidden or undocumented API endpoints?
+
No, and that is deliberate. The tool records the requests a page makes and checks the handful of conventional paths where frameworks publish API specs. It does not guess endpoint names, enumerate paths or fuzz parameters — that would make it a scanner rather than an analyzer, which is not what we built.

Related tools