Which checks does a site get?

The first three checks

• Page (HTTP). Passes on a 2xx answer. You can require a piece of text that the page must contain, which catches a page that answers but shows an error.
• Certificate (TLS). Verification, host name and expiry warnings.
• DNS records. The A records, and AAAA when the name has them now, and the name servers, mail servers, SPF, DMARC and CAA records. A change appears on the site’s What changed timeline and in an alert that says what was added and removed (how).

Beside these, the app tracks the signals that can hide a site from search (a page that becomes noindex, a robots.txt that starts blocking it, a canonical that moves to another host) and the expiry of the domain registration. Changes are listed on the same timeline, and a search-visibility risk queues an alert once a second check confirms it.

Checks you add

• Scheduled task (cron job). Your job calls a secret URL; a missed call opens an incident (how).
• API. A request with a method from GET to DELETE, an optional body, and assertions on the status, the response headers, values in a JSON body and the response time. The body and any secret header are stored sealed and are never shown again.
• TCP port. Opens a connection to a common service port and closes it again. Nothing is sent.
• Reachability. Connects (TCP) to port 443 or 80 and measures how long that takes. It is not an ICMP ping.
• DNS blocklists. Asks the public lists you choose about the site’s IPv4 addresses, at most once an hour.

The Security page

Beside the checks, Site security in the app (and the Security card on a site’s page) reads each site from outside, the way a visitor does (and, for a site whose domain you proved below, the way a search engine and an AI crawler do), and lists possible problems with the evidence it saw: injected scripts and frames from a new host, links and text a visitor cannot see, spam vocabulary, redirects to another site, software versions on a list of exploited flaws, missing security headers, and, after the proof below, pages that differ for Googlebot or an AI crawler and files that should never be public. A finding is a lead, not a verdict that the site was hacked, and Beamfar is not a firewall: it cannot block an attack.

• What it reads. The home page, the pages your checks monitor and some internal links, as many as the plan allows, all as a browser. Only for a site whose domain you proved (below), and only while Also read pages as search engines and AI crawlers is on, the first three pages are also requested twice as a browser, as Googlebot, as a visitor from a search result and as four AI crawlers, each time with Beamfar’s name added to the user agent. A site without the proof never receives a request that looks like Googlebot or an AI crawler.
• How to read a finding. A warning is alerted when it is new; a notice is only listed. Seen means the fact itself was observed (a file answered); Possible means an inference that can be harmless, such as a new analytics script. Open a finding for the evidence, what it means for search and the steps. Accept as expected leaves it out of later scans.
• Alerts. The first scan of a site only sets the starting point and sends nothing. New warnings after that reach your alert channels in one grouped message that starts with [SECURITY].
• What it cannot see. Files on the server, the database, the user list and backups, anything behind a login, an attack while it happens, and a hacker who checks Google’s real addresses (a request that only changes the user agent does not catch one, so Google’s URL Inspection stays the check that counts). A quiet scan only means that nothing was seen by the checks that ran; the page lists what was and was not checked.
• Who can do what. Everyone in the organisation reads the Security pages (a member who is limited to one client sees that client’s sites only). Owners, admins and members can ask for a scan, accept notices and switch the checks; owners and admins start the proof and see its DNS record, accept warnings and use the last scan as the new starting point. An accepted finding is shown again after 30 days. Security checks are part of some plans only.
• Where the software data comes from. Software versions are matched against the CISA catalogue of known exploited vulnerabilities, the NVD and OSV. This product uses the NVD API but is not endorsed or certified by the NVD. A finding that used OSV data names its source (for example “Source: OSV.dev / GitHub Advisory Database (CC-BY 4.0)”), and records from sources that do not allow commercial use are not used. The findings are also in the API, the AI assistant tools and the monthly client report.

Active checks and the proof of a domain

Active checks ask the site for well-known files that should never be public: a Git folder, .env files, backups of wp-config.php, phpinfo pages, backup archives and SQL dumps, .htpasswd, the WordPress debug log and a few more. Each is one plain GET request, no body or login is sent, redirects are not followed, and for an .env file only the names of the variables are kept, never their values. They run only after you prove that you control the domain, only over https, and at most once per scan interval of your plan. The same proof is what allows the crawler views above.

1. On the site’s Security page, under Settings, press Start the proof (owners and admins can). The page shows a DNS TXT record to publish.
2. Add that record at your DNS provider. It is also accepted one level up, at your registered domain.
3. Press Check now; Beamfar also checks by itself. The state is Waiting for DNS, Verified, Not verified (the record did not appear within three days) or Disabled (a record that was there is gone).
4. When it is Verified, switch Active checks for well-known files and, if you want them, Also read pages as search engines and AI crawlers on. Removing the proof or the record switches both off, and one site’s proof never unlocks another site. A site that is only an IP address has no DNS name and cannot be proven.

Beamfar has been tried on test pages only and has no customers yet.

Where our checks come from

A firewall, a security plugin or a host’s bot filter that blocks unknown visitors can block our checks too. The site then looks down to Beamfar while visitors reach it, and a security scan sees an error page instead of the site. To prevent that, allow our addresses, or the product token at the end of our User-Agent, before you add the site.

• Our name is in every request. The User-Agent ends with a product token: Beamfar-probe/<version> for the uptime checks, Beamfar-integrity/<version> for the security scans, Beamfar-crawler/<version> for the crawls and Beamfar-alerts/<version> for the alert webhooks. A rule on the token keeps working when an address changes.
• Search engine and AI crawler names. Only for a site whose owner proved the domain with the DNS TXT record (above), the security scans also ask for the first pages as Googlebot, as a visitor from a search result and as four AI crawlers, each with our token added. Every other scan reads the site as a browser. A rule that blocks an unverified Googlebot therefore meets only those requests, from the application host, and never turns into a false downtime alert.
• IPv4 and IPv6. The uptime checks use IPv4 unless IPv6 is switched on for their region. The application host can use either family, so where it has both, allow both.
• When the addresses appear. They are published here at launch, when the servers exist. If a server is ever replaced, its new address is on this page the same day.

Good to know

Which kinds a plan may create and how many checks a site can hold are plan limits; the Billing page lists them. The app checks from the outside: it does not log in to a site or run browser journeys, though an API check can send a secret header.