Sites, Domains & the Web

A working website is more than a running Apache. The domain has to resolve, the certificate has to be valid, the right machine has to answer, the CDN has to be in front of it, and the search engines have to know it exists. FrontierStack gathers all of that into the Sites pane and a small family of companion tools, so the whole chain — registrar, DNS, TLS, CDN, host, SEO — is visible and fixable from one window. This chapter covers the web above the stack; for the vhosts and certificates themselves see Chapter 4.

7.1The Sites pane and Domain Health

Open Sites from the sidebar. At the top sits the Domain Health section, a live dashboard that collects every hostname FrontierStack knows about: the local Apache and Nginx vhosts you have defined, the vhosts on linked servers, every Cloudflare zone on your token, and every domain in the registrar monitor. Each domain gets a row with a set of status badges; press Check on a row, or Check All in the header, and the app probes the domain end to end and colours the badges green or amber.

The point of the dashboard is to answer one question reliably: is this domain actually serving, and from where? Because the checks run against the public internet (a real DNS lookup, a real HTTP request, a real TLS handshake), they catch the failures a local config check never sees — a record that points at the wrong IP, an expired certificate, a Cloudflare zone stuck in "pending", a site that resolves but returns a 502.

7.2Proving domain ownership

Vendors verify that a domain is yours by asking you to publish a DNS TXT record only its owner could create — the same proof-by-DNS idea as ACME's DNS-01 challenge, but every vendor has its own record format. The Verify button on a Domain Health row keeps those formats in one place: pick the service — Google (Search Console / Workspace), Microsoft 365, Meta, Apple Business Manager, Atlassian, OpenAI, Stripe, GitHub organizations, or a custom record — paste the token from the vendor's console, and FrontierStack publishes the TXT record straight into the domain's Cloudflare zone. If the domain isn't on your Cloudflare token, it hands you the exact record to add at your DNS host instead. A bare token is completed automatically (paste abc123 for Google and the record becomes google-site-verification=abc123).

The sheet also shows the verification records already published on the apex — a quick audit of who this domain is currently proven to — and Check DNS queries public DNS (1.1.1.1) for the new record, so you know the proof is visible before you press "Verify" on the vendor's side.

For certificates, the Let's Encrypt service pane (Security & Secrets category) is a standing health check on the other kind of domain proof: it watches the ACME API, Let's Encrypt's status page and a domain's live certificate, and — because ACME clients renew when 30 days remain — alerts when a certificate is overdue for renewal, catching broken certbot/acme.sh automation weeks before visitors ever see an expiry warning.

7.3AI SEO and "Fix My Site"

Two of the badges on a domain row are not just diagnostics — they are buttons that hand the problem to the AI Administrator. Fix My Site takes a broken or misbehaving site and runs the assistant through a fixed playbook: reproduce the fault by curling the site locally with its Host header, read the relevant logs, check that Apache, PHP and the database are running, and then state the single most likely root cause with concrete next steps. With Allow changes off it only advises; with it on it may apply the reversible fixes (restart a service, correct a wrong value in a config file, repair the database). There is a WordPress-aware variant for the classic white screen, "Error establishing a database connection", broken permalinks and stuck maintenance mode.

The SEO action runs an on-device read-only audit: the assistant fetches the home page, robots.txt and the sitemap, scores the site out of 100 and writes a short report (titles, meta descriptions, headings, crawlability, structured data). The result opens in an SEO report sheet so you can read the findings and act on them.

7.4One-click CMS installs (Apps & CMS)

Installing a CMS is only the first day of its life; WordPress Sites covers the rest. Choose a host — This Mac or any fleet server — and scan for wp-config.php under the usual web roots, and every WordPress install on that machine appears with its core, plugin and theme versions and whatever is waiting to be updated. Update all exports the database before it touches anything, because a bad plugin update is recoverable and a lost database is not. Check integrity compares the core files against the checksums WordPress.org publishes, which is the quickest way to find a defaced or backdoored install; add a free WPScan token and the pane also checks your installed plugins and core against the vulnerability database, marking anything with no published fix. Multisite networks list their subsites. The remaining jobs are the ones that otherwise mean an SSH session and a half-remembered command: resetting the password of a locked-out administrator, search-replace to move a site between domains (WP-CLI rewrites URLs buried in serialized PHP, where a plain SQL replace corrupts them — so always dry-run first), cloning a site to staging, and exporting or optimising the database. A clone copies the files, gives the copy its own database, rewrites the URLs inside it and sets it to discourage search engines, so staging can never write to production or outrank it. Everything runs through WP-CLI over SSH, and the pane offers to install WP-CLI on any host that lacks it. Pin a site and Alerts will tell you about pending updates, a failed integrity check or a new vulnerability.

If your WordPress lives on managed hosting rather than your own machines, the hosting panes now list those sites too: WP Engine, Kinsta, Cloudways and Pressable each pull your installs through their API — environment, primary domain and status — and they roll up into Cloud Servers alongside your VPS instances, so one inventory covers everything you run. These are sites rather than machines, so they carry no power controls.

The Apps & CMS section installs a self-hosted CMS onto your Apache/PHP/MySQL stack in a single flow, each with its own pane: WordPress, Drupal, Joomla, Statamic, Grav, Kirby and Craft CMS. The installer downloads the app (or runs composer create-project for the Composer-based Statamic and Craft), extracts it into the document root, and — for the ones that need a database (WordPress, Drupal, Joomla, Craft) — creates the database and user and writes the config where the app expects it. The flat-file CMS (Grav, Kirby, Statamic) need no database at all. It then opens the app's setup or admin page so you can create your account (/wp-admin/install.php, /admin, /panel, /cp, /admin/install…), while FrontierStack wires the virtual host, PHP and trusted HTTPS around it. For the install folder you can pick a site Apache already manages — a menu prefills its domain, document root and port — or Choose… a new empty folder; a matching Apache vhost is created for a new folder, or updated when the domain is an existing site. If an install misbehaves, Fix My Site (AI) above debugs it.

7.5The Domain Registrar monitor

Sites tells you whether a domain works today; the Domain Registrars pane (in the DNS category) tells you whether it will keep working. Add a domain and FrontierStack watches three things on a schedule and raises an alert when any of them drifts:

• Expiry — the registration end date, registrar and nameservers, pulled over RDAP (with a whois fallback). Works for any domain, whatever the registrar.
• DNS — whether the domain still resolves (dig).
• SSL — the certificate expiry, checked directly with openssl.

A renewal warning fires when the expiry is within your reminder window, already past, or when auto-renew is off. For supported registrars the pane can import your domain list and auto-renew status by API — GoDaddy, Porkbun, Gandi, Value Domain, Route 53 (via the AWS CLI) and Cloudflare (reusing the Cloudflare token). Registrars without a usable list API (Namecheap, Squarespace, Onamae) you add by hand; RDAP still monitors them.

7.6Cloudflare: zones, DNS, cache and tunnels

The Cloudflare pane is where you paste an API token and choose which zones appear in the sidebar. Each zone you Pin to sidebar becomes its own pane with that zone's Cloudflare/DNS/HTTP/SSL health, DDoS and bot protection, WAF rules, Workers, CDN analytics, development mode and cache purging (everything, a list of URLs, or by prefix). Scope the token carefully: a read-only token lists zones, but DNS edits, certificate DNS-01 validation, Dev Mode, cache purge and zone creation each need their own permission, and creating a brand-new zone needs the account-level Zone · Zone · Edit permission. The pane links straight to Cloudflare's token templates, a Test Token button probes the live API and lists exactly which of those abilities the token has or lacks (reads are exercised directly; writes are probed with deliberately-invalid requests, so nothing is changed), and a Dashboard button deep-links into the Cloudflare web console for the current zone.

When a pinned zone shows a warning or its HTTP check has stopped answering, the pane's Diagnose button finds out why instead of leaving you with a coloured dot. It probes each layer of the serving path in order — the zone's state at Cloudflare, the public nameservers, DNS resolution, HTTPS through the edge (decoding Cloudflare's 52x errors: 521 origin down, 522 timeout, 524 the app or its database hanging, 525/526 origin TLS), the origin server's ports 80 and 443 directly, and finally the machine FrontierStack knows serves the domain: the local web server if that is this Mac, or a linked server's on-host monitor service states (a stopped mysql surfaces right in the report). When the public path is broken it also sweeps the fleet: which linked servers are up, which binds the origin IP, and which already serves this domain's vhost — so a host that went offline and took the sites' front-door IP with it is named directly, together with the server that could take over. Each layer is shown pass/fail, ending with a plain-language conclusion — which layer broke and what to do about it.

Cloudflare turns up across the app: the AI's dns_record tool writes records into a zone you manage and updates existing ones in place — including flipping a subdomain between proxied (orange cloud) and DNS-only — issue_certificate can validate over Cloudflare DNS-01, and email_auth_dns can publish SPF/DMARC for you (see Chapter 13). The same account also powers Cloudflare DDNS and the Cloudflare Tunnel for exposing a local site — both covered in Chapter 9.

7.7Hosting providers

Not everything you run lives on a Mac. The Hosting category brings VPS and managed providers into the same window. VPS providers — DigitalOcean, Vultr, Linode, Hetzner, Sakura and others — expose their servers through an API token: paste it, and the pane lists each server with plan, location, status and IP, and lets you power one on, off or restart with a confirmation. Dashboard-style providers (managed hosting such as Hostinger) store their token and surface quick links to the control panel, docs and sign-up. Either way the credential lives in the Keychain, and the servers you can reach over SSH become part of your fleet (Chapter 8).

7.8IndexNow: instant search-engine submission

When a page changes, you do not have to wait for a crawler to notice. IndexNow Manager (in SEO & Marketing) tells the participating engines — Bing, Yandex, Seznam, Naver and others — immediately. Pick one of your managed sites, press Install Key File, and FrontierStack writes the <key>.txt file into the site's document root so the engines can confirm you own the key; Verify checks it is being served. Then submit a single URL, fire off the pending queue, or feed it from a sitemap, and it can auto-submit on a schedule. Everything goes to api.indexnow.org, which fans out to all participating engines; the URL's host must match the selected site and its key.

7.9Site Transfer: copying sites between machines

Two tools move a site without a manual rsync dance. Copy Websites Between Apache handles the local case: when you have more than one Apache install on the Mac (say a Homebrew one and an old Server.app one), choose the source install, tick the sites you want, and FrontierStack copies their document roots and vhost definitions into the currently selected Apache. Sites with the same domain are overwritten, so it is also how you re-import after a migration.

To move a site to another machine, the AI's promote_site tool clones a local site to one named fleet host: it uploads the document root, writes the vhost (Apache or Nginx) on the far side, reloads the web server, and can add the Cloudflare A record pointing at the new host — the same steps as a manual fleet push, in one call.

7.10Provisioning a new web project

The pieces above combine into a single flow for standing up a project's infrastructure from nothing. The idea is a clean division of labour: your AI tool (over MCP) owns the code; FrontierStack owns the infrastructure. The built-in Provision Web Project skill walks the assistant through the recipe in order:

1. Discover — inventory the target, its privilege access, installed Apache/Nginx and connected DNS provider; identify or install missing prerequisites before making a public change.
2. Zone — cloudflare_zone_create makes the Cloudflare zone and returns the nameservers to set at the registrar (and tells you plainly if the token lacks account-level zone-create rights).
3. Vhost + folder — vhost_create defines the Apache/Nginx site. If you did not provide a document root, FrontierStack creates an empty platform-appropriate folder and reports its path. It does not design or generate site content.
4. DNS — dns_record points the name at the host.
5. TLS — issue_certificate issues a Let's Encrypt certificate.
6. Preview — a temporary share for a localhost test point (Chapter 9).
7. Promote — optionally promote_site clones it onto a fleet host.

Domain registration can join the front of this recipe through domain_register, so an agent can in principle buy the name, create the zone, stand up the vhost, issue the certificate and clone to the fleet — with every money-spending or system-changing step previewed for your approval first.