Beamfar
Sign inStart the 14-day trial

Monitoring Shopify, Webflow and WordPress sites from the outside

By the Beamfar team. Published . Updated . 6 min read.

Agencies look after sites on very different stacks, and a monitor that needs a plugin or an agent on each one does not scale. Monitoring from outside, the way a visitor and a search engine reach the site, works on any stack. It does not see inside the server. The useful question is what each platform leaves in your hands.

Beamfar is an independent product. It is not affiliated with, endorsed by, sponsored by or certified by WordPress, Shopify or Webflow or their owners. The names are used only to say which kind of site this page is about, and they belong to their owners.

What outside-in monitoring sees

From outside you can see, on any platform:

  • whether the page responds, how fast, from which regions and with which status;
  • the final URL after redirects;
  • the TLS certificate: issuer, dates, replacement;
  • DNS answers for the hostname and how they change;
  • the response headers and the head of the page: robots meta, X-Robots-Tag, canonical, title;
  • /robots.txt and whether it blocks the page;
  • the domain’s registration expiry, where the registry shows it.

You cannot see CPU, memory, database health, plugin versions, failed logins or what happens behind a login. Server-side monitoring is a different job. The aim here is to catch what a visitor and a crawler would meet.

Hosted platforms: what stays yours

On a hosted platform the vendor runs the servers. Uptime of the platform itself is not your lever, and an outside monitor still tells you when the client’s site is affected, which is worth knowing before the client does. What remains in your hands is the layer between the domain and the platform.

Shopify

For a custom domain Shopify’s instructions for a manual connection ask for an A record pointing to Shopify’s IPv4 address, an AAAA record for IPv6, and a CNAME for www pointing to shops.myshopify.com, and they tell you to delete other A and AAAA records on the domain. Its page says the domain can take up to 48 hours to go fully live after a change.

That is your area of risk:

  • DNS records edited later by someone adding a service, which can leave a second A record or remove the www CNAME.
  • The primary domain and redirects: check which host the store treats as primary and that the other hosts end up there, so search results do not show odd hosts.
  • Theme changes that add or lose SEO tags: titles, canonicals, robots meta on collection pages.
  • Domain expiry and the registrar account, which belong to the client or to you.
  • Checkout: the store domain and the checkout may differ; check the pages visitors use.

Webflow and other site builders

On a site builder the same layers apply. Check the vendor’s current instructions for DNS records, and monitor what you can see.

  • Publishing state. A page that is unpublished or a site that is in a staging domain mode is invisible to visitors; the page will respond with an error or a default page.
  • Search-visibility settings. Builders have site-level and page-level settings to hide pages from search engines, and a setting meant for the staging domain can be switched on for the live one. The result is the noindex problem described in Noindex after a deploy.
  • Custom domain DNS and certificate. A change of DNS at the client’s registrar can stop the builder issuing or renewing the certificate for the custom domain.
  • Redirect rules defined in the builder: check the final URLs of important old links.

Other hosted stores and builders

The same checklist applies: domain and DNS, certificate, redirects, search visibility settings, and the pages visitors use.

WordPress and other self-managed sites

Here you also own the server, or the hosting account, and the failures are more varied.

  • Plugin and theme updates break pages. A white screen can return status 200 on some stacks (see What a 200 response hides).
  • Scheduled tasks depend on WP-Cron, which, as the WordPress handbook explains, runs on page loads and not on a clock, so tasks run late on low-traffic sites (see Heartbeat and cron job monitoring).
  • The “discourage search engines” setting can be copied from staging along with the database.
  • Caching layers: the cache can serve a healthy page while the application behind it is down, or a stale page after a fix. Check pages that bypass the cache, and the cache headers.
  • Security incidents may change content without changing the status code.
  • PHP, database or disk errors show up as 500, as a blank page or as a “database connection” message on a 200 page. Check expected text.

Add server-side monitoring (CPU, disk, backups, updates) for these sites. An outside monitor will not replace it.

One guide for each platform

The same outside checks apply everywhere, because they use only HTTP(S), TLS and DNS. What differs is what breaks, and which setting or background task is worth a check of its own. Each guide below lists the failures of one platform, with sources from the platform’s own documentation:

A platform that is not on the list works the same way: if the site answers over HTTP(S), Beamfar can check it, and the platform’s own switches (a password, a hide-from-search setting, a maintenance mode) are the first thing to look up.

A checklist for any stack

  1. A monitored URL for each template: home, a content page, a product or service page, the contact form page, the cart or booking page.
  2. Expected status and text for each.
  3. The certificate and its expiry for each hostname that serves visitors.
  4. DNS change detection for the main hostname.
  5. A check for noindex, robots.txt blocking and canonical on the main templates.
  6. Domain expiry for the registered domain.
  7. A named owner for each alert and a place to record what happened.
  8. A monthly report that says what was watched, what was found and what you did.

What to tell the client

Say what the monitoring covers: “we watch what your customers and Google see, from outside, every minute”. Say what it does not: “it does not read your server or your orders”. That honesty prevents the argument after the first miss, and it explains why a care plan includes both.

How Beamfar helps

Beamfar is built for this outside-in view: it needs nothing installed on the site, so the same setup works on WordPress, Shopify, Webflow, Laravel, static and headless sites. It watches the page, the certificate, DNS records, redirects, SEO-risk signals and domain expiry, and writes the monthly report and public status page per client. It does not look inside the server, run plugin or update checks or test a checkout journey.

Questions

Can I monitor a Shopify store without installing anything?

Yes. A monitor reaches the store the way a visitor does. It sees the response, the certificate, the DNS records and the SEO tags, but not the platform’s internals or your orders.

What can go wrong with a custom domain on a hosted platform?

Records changed or added at the registrar, a second A record left behind, a missing www CNAME, an expired domain or a certificate that stops renewing after a DNS change.

Why monitor WordPress from outside if I have a security plugin?

A plugin runs on the same server it protects and may not run when the server or PHP is broken. An outside check shows what visitors and search engines receive, which is a different and complementary view.

Do I need server monitoring as well?

For self-managed sites, yes: disk, memory, backups and updates are invisible from outside. For hosted platforms the vendor covers the servers.

Sources

Read on . Standards and vendor pages change; confirm the current text before you rely on it.

Terms used in this guide

  • Uptime monitoringUptime monitoring requests a website from outside at intervals and alerts when it fails to answer. What it measures, what it misses and how it is confirmed.
  • DNS recordA DNS record is one entry in a domain’s zone that maps a name to data such as an address, a mail server or a text value. The common types and what breaks when one changes.
  • NoindexNoindex is a robots directive, set in a meta tag or header, that tells search engines not to keep a page in their index. How Google reads it and its common failure.
  • CNAMEA CNAME record makes one name an alias of another. Why a name with a CNAME cannot hold other records, which blocks it from the root of a domain.

Know first. Know why. Tell your client before they call.

Paste your client list. Both regions start checking.

Start the 14-day trialWhat Beamfar watches

No card for the trial.