Site Info
Title, description, stack, and tech used on any site.
No known technologies detected from the response.
What does each field mean?
Field reference
HTTP status
Status code returned by the final URL in the redirect chain. 200 OK is healthy; 301/302 means there's another hop (see redirect chain); 403/404/500 indicate availability problems.
Server
Free-form string the server announces — <code>nginx</code>, <code>cloudflare</code>, <code>Apache/2.4</code>, <code>caddy</code>. Some servers redact or fake this header for security; absence is not a problem.
Latency
Round-trip plus TLS handshake plus server first-byte. Single-origin measurement (our server location), so geographic distance and edge caching all influence the number. Use as a rough freshness signal.
Redirect chain
Sequence of 3xx redirects. Two hops (HTTP → HTTPS → www) is normal; three or more usually means misconfiguration. Each hop costs an extra RTT and hurts SEO.
Language
Read from the <code><html lang="..."></code> attribute. Used by browsers for hyphenation and translation prompts, by search engines for locale targeting, by screen readers for pronunciation. Missing or wrong values hurt accessibility.
Meta tags
Title appears in the browser tab and as the headline in Google SERPs (~50–60 chars). Meta description shows under it (~150–160 chars). Both should be unique per page and concise — generic or duplicate metadata hurts CTR.
Open Graph
Open Graph tags (<code>og:title</code>, <code>og:description</code>, <code>og:image</code>, <code>og:url</code>) control how the page renders when shared on social networks. Missing or low-res images mean blank or ugly previews.
Detected technologies
Wappalyzer-style detection: WordPress, Drupal, Next.js, Cloudflare, Google Analytics, etc. Signals: response headers, generator meta, well-known asset paths, inline scripts. Useful for competitive research and security recon (knowing the stack helps target audits).
About this tool
Site Info fetches a website's landing page from our Frankfurt server and reports everything that page broadcasts about itself: the HTML <title>, the meta description, Open Graph and Twitter Card metadata, the favicon URL, the canonical URL, language hints, and a fingerprint of the underlying tech stack (server, CMS, frameworks, analytics, ad networks, CDN). The check uses a real browser-style HTTPS request — including following up to five redirects and reading HTTP/2 responses — so what you see is what a normal visitor would see.
Tech detection runs against signatures for ~1,500 products: server headers (nginx, cloudflare, litespeed), HTML markers (generator meta, framework-specific class names, asset paths), and JavaScript globals exposed on first render. Each detection is shown with a confidence level and the snippet that triggered the match. SSL/TLS details, the response chain (every redirect with its status code), and a render-time estimate are included in the same report.
When to use this tool
- Competitive intelligence. See what CMS, framework, analytics, and ad network a competitor uses without poking around their DOM by hand.
- SEO audits. Confirm title, description, Open Graph, canonical, and language tags are all present and correctly populated.
- Stack archaeology. Identify when a site was last redesigned by checking versions of detected libraries.
- Vendor due diligence. Quickly verify a provider really does run on the platform they claim in their pitch.
What we deliberately do not do
No JavaScript execution. We fetch the raw HTML response and parse what it contains, including inline<script> tags — but we do not render the page. This means client-side-only frameworks (a pure SPA with empty <body>) will leak less information; for those we rely on response headers and the bundle URL paths to fingerprint the stack. Sites that block bot traffic at the edge may return a cleaner page than a real browser would — the result honestly reflects what their server gave us.