Check a website now: the free site check.
Enter a web address. Beamfar runs one live check from this server and shows what it found: the page, redirects, certificate, DNS, search settings and the domain registration date.
What a result looks like
www.birch.example
- Answers200 in 240 msFine
- Redirects1 hop, ends on httpsFine
- Certificate12 days leftLook at this
- DNSA, AAAA, MXFine
- Searchindex, followFine
- Domainuntil 14 Jan 2027Fine
What the check looks at
The same probes Beamfar uses to monitor a client site, run once. Each result says why it matters to an agency.
- Does it answer?
- The status, the protocol and the timings: name lookup, connection, secure handshake and first byte.
- Redirects
- Every step from the address you typed to the final page, and whether it ends on https.
- Certificate
- Who issued it, who it is for, when it expires and how many days are left.
- DNS
- Address, alias, name server and mail records, asked of two public resolvers.
- Search settings
- noindex in the robots meta tag or the X-Robots-Tag header, whether robots.txt blocks the page, and which address the page calls canonical.
- Domain registration
- The expiry date from the public RDAP service, when the domain ending publishes it.
What happens to the address you enter
One check, then nothing kept. Only public websites, only the standard web ports.
- Nothing is kept
- The address is used for this one check and then forgotten: no database row, no log line, no cookie, no link to share the result. Only rate-limit counters are kept: hashed counts per network range and overall, for at most two days, never an address of a site.
- Only public websites
- Addresses on private networks, loopback, link-local and cloud-metadata ranges are refused, and so are redirects to them. Only the standard web ports 80 and 443 are checked. Each name is looked up once and the connection goes only to the address that passed. Checks are limited per network and overall, and need a short puzzle to be solved by your browser.
The site you check will see a few requests from Beamfar-probe in its logs (the page, each redirect hop and robots.txt), from this server. This is one reading from one place: it can differ from what visitors elsewhere see. That is why Beamfar monitors from two regions.
Questions
Is the site check free?
Yes, there is no account and no payment. It is rate limited so that it stays available for everyone.
Is the address I enter stored?
No. It is used for the one check and not saved or logged. Only hashed rate-limit counters are kept, per network range and overall, for at most two days, and they never hold the address.
Which ports does it check?
Only the standard web ports 80 and 443, including for redirects and robots.txt. Other ports are refused.
Can I check a site on my own network or localhost?
No. Only public websites can be checked, so addresses on private networks, loopback and cloud metadata ranges are refused.
Why does it ask my browser to solve a puzzle?
A short calculation, about a second, makes automated bulk use costly while keeping the page free of cookies and third-party scripts.
Why is one reading not enough?
One check from one place can be wrong. Beamfar checks every client site from two regions and calls it down only when both agree.
Guides that go with this page
Longer reads on the same ground, in plain words, each with its sources.
- Redirect chains after a site migrationHow chains and loops appear after a migration, how Google treats each status code and how to repair them.
- SSL certificate expiry on client sitesWhy certificates still expire, what shorter lifetimes change and a routine that catches expiry early.
- DNS changes that break client websitesThe DNS mistakes that take sites and email offline, how TTL hides them for hours and a safe change checklist.
- Noindex after a deploy: how sites vanish from GoogleHow a leftover staging noindex removes a site from search, how Google reads it and a deploy checklist.
- robots.txt mistakes that hurt a client siteThe robots.txt mistakes made on launch day and what Google and RFC 9309 say about errors, wildcards and caching.
- Canonical tag mistakes on client sitesThe canonical link errors that point search at the wrong URL and a checklist for catching them after every release.
- Domain expiry and RDAP: never lose a client domainHow domains lapse, what registrars must warn about, how RDAP exposes the expiry date and a routine for agencies.
Watch it from two regions.
One reading is a snapshot. Add the site and get the evidence every minute, from two regions.
No card for the trial.