Check a website

HTTP, DNS, security headers, caching, metadata and redirects — one public website.

Worker → website. Results describe the Worker's connection, not your device. Your URL is sent only when you start.

Check from my device Terminal or Agent

The Worker may reach a service that your app cannot. Run the CLI in the environment where the problem occurs. Generating or copying a command does not run a diagnosis.

Target URL Example: https://example.com HTTP/HTTPS · ports 80/443

Syntax is checked here; the CLI will fail closed for private or sensitive targets.

Run mode Terminal Agent

npm exec --yes
                  --package=https://github.com/flreey/netokay-cli/releases/download/v0.3.0/netokay-0.3.0.tgz
                  -- netokay diagnose 'https://example.com/'

Target URL accepted. Copy ready.

Run the check

Use the environment that needs to connect

Enter the full HTTP or HTTPS URL, including its path. This command supports public HTTP on port 80 and HTTPS on port 443. Leave out credentials, query strings, and fragments.
Copy the command into the terminal where the problem occurs. It uses the GitHub v0.3.0 prerelease package and requires Node 24 and npm. Review the command before running it.
Read the terminal result. The CLI applies the final target policy and performs the diagnosis. A generated or copied command has not yet tested anything.

What we check

Seventeen operations, thirty-seven result groups. Each runs from the NetOkay Worker with its own time limit and request budget, reads only what it needs, and reports what it could not observe as unknown rather than as a pass. Advisories at the top of the results rank what was found from critical to pass and jump to the evidence.

Website response

HTTP status, DNS, security and cache headers, page metadata and redirect.

HTTP response: One GET request from the NetOkay Worker to the URL you entered, recording the status code and the time until response headers arrived. A 2xx confirms the server answered this request. 4xx and 5xx mean the server replied with an error; a timeout or failure does not identify a unique cause.
DNS addresses: A and AAAA records from Cloudflare DNS-over-HTTPS. Every address is checked against the public-address policy before any request is sent. Missing AAAA records mean no IPv6 path. Answers describe the resolver view, not the address the HTTP connection used.
Security headers: Presence and value of six common response headers: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. Missing headers widen the attack surface for clickjacking, MIME sniffing and script injection. A missing header alone does not prove a vulnerability.
Caching: Cache-Control, Expires, Age, ETag and Last-Modified on this response. Cache headers decide how browsers and CDNs reuse a response. They describe this response only, not the whole CDN configuration.
Page information & SEO tags: Title, meta description, canonical, robots meta, viewport, language, Open Graph and Twitter Card tags, headings, images without alt text, link counts and JSON-LD types, parsed from the first 128 KiB of HTML. JavaScript is never executed. These tags decide how search engines index the page and how links preview on social platforms. Duplicate H1s, missing descriptions or a noindex directive are common, cheap-to-fix SEO problems.
Redirect: Whether this response is a 3xx redirect and, if so, whether its destination passes the public-URL policy. Redirect destinations are followed only when you run the redirect chain check.

Crawling & SEO files

robots.txt, sitemap and security.txt.

Crawl rules (robots.txt): Parses /robots.txt: user-agent groups, allow and disallow counts, crawl-delay, declared sitemaps, and whether all crawlers or well-known AI crawlers are blocked. A stray "Disallow: /" removes the site from search. The file also tells you how the site treats AI crawlers.
Sitemap: Fetches the sitemap declared in robots.txt or /sitemap.xml, expands a sitemap index by sampling up to three same-origin children, and counts URLs and lastmod dates. Sitemaps help crawlers discover pages and learn when they changed; missing lastmod values waste crawl budget.
security.txt: Looks for /.well-known/security.txt (then /security.txt) and checks the Contact and Expires fields and a PGP signature. RFC 9116 gives researchers a standard way to report vulnerabilities; an expired file is treated as absent.

Headers, cookies & firewall

All headers, ten security headers, HSTS, cookie attributes and WAF/CDN fingerprint.

All response headers: Every response header except Set-Cookie, capped at 64 headers and 1,000 characters each. Server and X-Powered-By headers disclose software versions that make targeted attacks easier.
Security policy (10 headers): CSP (with directive analysis), HSTS, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy, Permissions-Policy and the three Cross-Origin policies. 'unsafe-inline' or wildcard sources weaken CSP; a missing frame protection enables clickjacking.
HSTS: Parses Strict-Transport-Security: max-age, includeSubDomains and preload, and whether the policy meets preload-list requirements. HSTS stops browsers from ever trying plain HTTP; preloading protects even the first visit.
Cookies: Names and attributes of cookies set by this response: Secure, HttpOnly, SameSite, persistence, Domain and Partitioned. Values are never read. Cookies without Secure can be sent in clear text; without HttpOnly they are readable by injected scripts; without SameSite they can be sent cross-site.
Firewall / CDN: Header and cookie-name fingerprints for common WAF and CDN vendors. Only header names are reported as evidence. Knowing the edge vendor explains blocks, challenges and rate limits your application may hit.

Redirect chain

Up to three redirects and the HTTP to HTTPS upgrade.

Redirect chain: Up to three redirects followed from the URL, each destination re-checked against the public-URL policy and DNS admission. Long chains slow every visit and leak ranking signals; loops break the site.
HTTP to HTTPS: Whether the plain-HTTP entry point of the same host redirects to HTTPS and whether that redirect is permanent. An HTTP entry that serves content directly leaves first visits unencrypted; a temporary redirect prevents browsers from remembering the upgrade.

Additional DNS

NS, MX, TXT and CAA records.

Nameservers: NS records for the domain. Fewer than two nameservers is a single point of failure.
Mail servers: MX records for the domain. No MX record means the domain does not receive mail; a single record has no failover.
TXT records: All TXT records at the domain apex. TXT records carry SPF, verification tokens and service ownership proofs.
Certificate authorities: CAA records restricting which certificate authorities may issue for the domain. Without CAA any public CA can issue a certificate for the name.

Email authentication

MX, SPF, DMARC, DKIM and BIMI.

MX records: Mail exchangers and priorities. A null MX (".") declares the domain sends no mail.
SPF: The v=spf1 TXT record: its all-qualifier, include count, DNS-lookup terms and whether more than one record exists. +all lets anyone send as the domain; more than ten lookups makes SPF fail permanently; two records invalidate both.
DMARC: The _dmarc TXT record: policy, subdomain policy, percentage, alignment and whether aggregate reports are requested. Report mailboxes are redacted. p=none only monitors; quarantine or reject is what stops spoofed mail.
DKIM: Looks for public keys at six common selectors (default, google, selector1, selector2, k1, mail). DKIM proves mail was not altered in transit. A miss on these selectors does not prove DKIM is absent.
BIMI: The default._bimi TXT record and whether it points at a logo and a verified mark certificate. BIMI shows a brand logo in supporting inboxes when DMARC is enforced.

DNSSEC

DS, DNSKEY and resolver validation.

DNSSEC: DS and DNSKEY records, signing algorithms, and whether the resolver validated the answer (AD flag). DNSSEC lets resolvers detect forged DNS answers; a DS record without validation indicates a broken chain.

Tech stack

Servers, frameworks, CMS, analytics and third-party hosts.

Tech stack: Header, meta-generator, resource-URL and markup fingerprints for servers, frameworks, CMSs, analytics and third-party scripts, plus the third-party hosts the page loads from. No browser is used. Third-party scripts are the usual source of privacy leaks and supply-chain risk. Absence here is not evidence of absence.

Lighthouse quality

Performance, accessibility, best practices and SEO scores.

Lighthouse quality: Google PageSpeed Insights (mobile) performance, accessibility, best-practices and SEO scores with LCP, FCP, CLS, TBT, Speed Index and TTI. Core Web Vitals are a Google ranking signal; accessibility failures exclude real users.

TLS audit

Qualys SSL Labs grade per endpoint.

TLS audit: Qualys SSL Labs assessment: per-endpoint grade and warnings. Cached results up to 24 hours old are reused; a fresh assessment can take a few minutes. Grades below A usually mean weak protocols or ciphers, a certificate problem or missing forward secrecy.

Server location

Country, city, ASN and organisation of the server.

Server location: Country, region, city, time zone, ASN and organisation for the first resolved address, via ipwho.is. Where the server sits explains latency and data-residency questions. This is the target’s address, never yours.

Archive history

Wayback Machine first and latest snapshots.

Archive history: First and most recent Wayback Machine snapshots and the years with captures. Archive depth hints at how long a site has existed and whether it recently changed hands.

Global ranking

Tranco popularity rank.

Global ranking: Tranco rank for the domain (or its parent), combining several popularity lists. A rank in the top million is one signal that a domain is established rather than throwaway.

Threat feeds

URLhaus and PhishTank listings.

URLhaus: Whether abuse.ch URLhaus lists the host as distributing malware. A listing means recent malicious URLs were observed on this host.
PhishTank: Whether PhishTank has the URL in its phishing database and whether it is verified. Listed URLs are blocked by many browsers and mail filters.

DNS filter lists

Whether family and malware resolvers block the host.

DNS filter lists: Resolves the host through Cloudflare Malware, Cloudflare Family, AdGuard and AdGuard Family DNS and compares with an unfiltered resolver. Sinkholed or refused answers mean users behind those filters cannot reach the site at all.

Subdomains

Host names disclosed by Certificate Transparency.

Subdomains: Host names disclosed by public Certificate Transparency logs (crt.sh) for the apex domain. Nothing is sent to the target. Forgotten subdomains often run outdated software or point at abandoned services.

Open ports

TCP reachability of ten well-known ports.

Open ports: TCP connect attempts to ten well-known ports (FTP, SSH, SMTP, HTTP, HTTPS, MySQL, PostgreSQL, Redis, 8080, 8443) with a 2.5 second limit each. Nothing is sent after the connection opens. Database or admin ports reachable from the internet are the most common critical exposure. Hosts behind a CDN answer for the CDN, not the origin.

Frequently asked questions

Is this the same as web-check or a Lighthouse run?

It covers similar ground with a smaller footprint: no browser is launched, so there is no screenshot and technology detection is header and markup based. Lighthouse scores come from Google PageSpeed Insights when the instance has an API key; the TLS grade comes from Qualys SSL Labs. Everything else is measured directly by the Worker.

Will the target site notice?

Yes. It receives a handful of GET requests identified as NetOkay-Website-Check/2.0 (+https://netokay.net/about/), plus TCP connects to ten ports if you run the port check. Check only sites you own or are authorised to test. Site owners can ask to be excluded on the About page.

Why does a check say “owner opt-out”, “disabled here” or “not configured”?

The site owner asked not to be checked, the operator switched that check off on this instance, or the upstream service needs an API key that is not configured. None of these say anything about the target.

Why do results sometimes appear instantly?

Completed results are cached on the edge for up to 10 minutes per target and check, so a shared link or a repeated run does not send new requests to the site. Cached cards say so in their evidence.

What does this result mean?

A 2xx response means this HTTP request succeeded. A 3xx response may point to another location. It is followed only when you choose Follow redirects. A 4xx or 5xx response means a server replied with an error; it does not mean the network connection failed. A timeout or unavailable result does not identify a unique cause.

If your app still fails, check the same URL from its environment using the terminal option above. Compare proxy, DNS, certificates and authentication settings, then retry the original operation. Neither the Worker nor a separate CLI process verifies the application’s internal client.

Read Evidence Compare browser and terminal Application still fails?

Try these free steps first

Check the exact URL and port, retry in the failing environment, and compare that environment’s network, proxy, and certificate settings. Use the application’s own logs to investigate what the CLI could not observe.

Starting a web check sends the URL to the NetOkay Worker and its hostname to Cloudflare DNS. The target receives requests from the Worker; some checks also send the hostname to public third-party sources named on each card. NetOkay application code does not store the URL, the result or your address, or send them to analytics or partners; completed results are edge-cached for at most 10 minutes. Page memory is cleared when you leave or reload; copying a command writes it to your clipboard.