TL;DR
- In 2026 we rebuilt or launched sixteen of our own properties on Next.js and Vercel: the advisory site, the sister brands for hosting and design, diagnostic tools, blogs, a client's reference site, and converted WordPress properties with years of content
- Built quickly by one person, they drifted. There was no single list of what a finished site should include, so every new build re-decided it
- We wrote the standard: thirteen core features and five secondary ones, from a Content Security Policy and security headers to form protection, rate limiting, repeat-submission cooldowns, blocked senders, sitemaps with real modification dates, a security contact file, and structured data, then audited every site and worked the gaps
- A dependency security sweep followed across the sixteen sites plus two outside the program
- On October 22, 2026, three critical and high Next.js advisories were disclosed. Every site in the sweep was bumped to the patched release and merged by the afternoon of October 23, with a note per site on whether the vulnerable path was reachable
Sixteen Sites and No Definition of Done
Advisory is easier to sell when you can show your own house. Over 2026 we moved our properties off WordPress and onto Next.js on Vercel: the advisory site, Concierge Web Hosting, Concierge Web Design, the free diagnostics at serpfu.com, MegaPromoters, a how-to blog, a status page, a public reference of unsolicited outreach, and two converted content sites, one with 185 curated posts and one with a catalog of several thousand products migrated into typed data.
Built fast by one person, they were inconsistent in the ways that matter. One site had a strict Content Security Policy; another had none. Some contact forms had per-IP rate limiting and a 72-hour cooldown per sender; some would accept anything. Three sites had a security contact file; thirteen did not. Only one had site search.
What the audit in July 2026 found across thirteen sites:
- Three reference implementations meeting nearly every core feature
- A middle tier missing robots rules, security.txt, or the form cooldown and block list
- A weakest tier lacking a 404 page, a sitemap, code-based robots, and security.txt, two of them also lacking CSP and rate limiting
- Site search present on one site, security.txt on three, llms.txt, Open Graph images, and JSON-LD on two
Write It Down, Audit, Sweep, Patch
The standard. Thirteen core features every site must have: a real 404 page, a Content Security Policy and security headers, a sitemap with true modification dates, code-based robots rules, security.txt, a contact stack with Turnstile, per-IP rate limiting, a repeat-submission cooldown, a blocked-senders list, spam signals, analytics, and a verified recipient. Five secondary ones: llms.txt, Open Graph images, JSON-LD, site search, and a safe-browsing verification. The standard lives as a reusable implementation guide so a new site starts from it instead of from memory.
The audit. Every site checked against every item, in one table, with the gaps named. Fixes were propagated from the reference implementations outward rather than re-invented per site.
The sweep. A dependency security sweep ran across the sixteen program sites plus two outside it, with advisories checked per site and the dependency overrides recorded so the next sweep can diff against this one. Fourteen of eighteen were complete by late October.
Patch day. On October 22 three advisories against the framework were published, two of them critical. By the afternoon of October 23 every site in the sweep was on the patched release and merged, each with a note on whether the vulnerable path was reachable in that site's configuration. Sites still mid-sweep were pulled forward and patched with the rest.
What It Means for Clients
- Every new site starts from the checklist, so "did we add security.txt?" is never a question again
- A fleet-wide patch in under 24 hours is a demonstrated capability, not a promise
- Reachability documented per site, which is the difference between "we updated" and "here is your exposure"
- A reusable standard that applies to client builds on the same stack, which is how a client's reference site made the list
We recommend the same discipline to clients because we have had to apply it to ourselves.
Frequently Asked Questions
What should every small-business website include before launch? A real 404 page, security headers including a Content Security Policy, a sitemap with accurate dates, robots rules, a security contact file, a contact form with bot protection, rate limiting and a repeat-submission cooldown, analytics, and a verified recipient address. That is the core list. Structured data, Open Graph images, and site search come next.
How do you patch many sites at once when a framework advisory drops? By already knowing what each site runs. A sweep that records every site's dependency versions turns a disclosure into a list of version bumps. The time-consuming part is checking whether each site is reachable through the vulnerable path; we do that per site and write it down.
Why document reachability instead of just updating? Because "we updated" does not answer the question a client, an insurer, or an auditor will ask: were we exposed? A one-line note per site, written the day of the patch, answers it.
Does this apply to WordPress sites? The checklist does; the mechanics differ. WordPress sites get the same headers, form protection, sitemaps, and security contact file through configuration and plugins, and patching is a version switch on managed hosting. The standard is platform-agnostic; this write-up is about the Next.js fleet because that is where we proved it.
Why run this on your own sites first? Because advice costs nothing to give. Applying a standard to sixteen sites you own, auditing them in a table, and patching them in a day is the evidence that the advice is practical. Clients get the checklist that survived that.