How Foglift.io Reached 100 in SEO, Security, and Accessibility

Published August 1, 2026 · Updated August 12, 2026 · 12 min read

Foglift is a free website audit tool that handles Cloudflare and WAF blocks by identifying the access layer before it calculates a score. It recognizes Cloudflare, Akamai, Imperva, and generic firewall challenge signatures, makes one bounded retry with a browser-profile user agent, and returns an explicit access-blocked result when the retry fails. A challenge page never becomes the website's Technical Audit score.

Foglift.io currently earns 100 in SEO, security, and accessibility on that same Technical Audit. Performance is 90, and AI Readiness is 70. This implementation log covers the firewall boundary, the engineering work behind those scores, and the 248 KB homepage constraint that remains open.

The current audit snapshot

The current snapshot comes from an August 12, 2026 audit. It returned the same category scores as the two August 2 repeatability runs, while the HTML warning increased from 247 KB to 248 KB. You can inspect the dated public report or run the same free Technical Audit against https://foglift.io.

The starting point was already strong. On April 6, our session log recorded SEO 100, security 100, accessibility 100, performance 89, and 88 in the audit's former AEO field. The scoring contract has changed since April, so the old 88 and today's AI Readiness 70 are different measurements. We do not use them as a before-and-after pair.

The useful history is at the issue level. It shows which changes removed an audit finding and which changes left the same warning in place.

1. We made security headers part of the deployment contract

Our March benchmark found that 26 of 28 SEO-tool sites had at least one security-header gap. Twenty-five were missing Content-Security-Policy. Foglift's current production response sends all six headers checked by the Technical Audit:

Content-Security-Policy: default-src 'self'; ...; object-src 'none'; frame-ancestors 'none'
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

The implementation is split across deployment configuration, the Next.js response-header configuration, and middleware because the public embed route needs a narrower framing exception. The production result is easy to verify:

curl -I https://foglift.io

This work maps cleanly to the security score. The audit checks the response itself, and the current response contains each expected header. MDN documents the reason for each control: CSP limits the resources a page can execute, HSTS tells browsers to use HTTPS for future connections, and Referrer-Policy controls how much referring URL data leaves the page.

The practical lesson is simple. Security headers are high-leverage audit fixes because the evidence lives in one HTTP response. Configure them globally, add route-specific exceptions deliberately, and test the live headers after deployment.

2. We treated JSON-LD as page-level data

The homepage currently exposes WebApplication, SoftwareApplication, Organization, HowTo, and FAQPage entities in its server HTML. Editorial pages add Article data and use FAQPage only when the same questions and answers are visible to readers.

That distinction matters. Schema.org defines Article as a creative work such as a news article or report, while FAQPage represents a page containing questions and answers. We stopped treating one site-wide schema block as enough. Each route now describes the thing that route actually contains.

Our April comparison-page work gives a concrete example. The old /vs/ template had thin structured data and no FAQ content. We added visible questions, matching FAQPage JSON-LD, citations, and richer page entities across the comparison set. Later scans of two upgraded comparison pages reached 85 and 86 in the former AEO scoring model, up from an earlier 81 baseline for those specific routes. That historical field has since been retired from public positioning, but the implementation lesson still holds: page-specific schema creates cleaner extraction units than a generic organization block alone.

We use three checks before calling a schema change complete:

1. The structured data parses as JSON.
2. The facts match the visible page.
3. The canonical URL, title, description, and modification date agree across metadata and JSON-LD.

3. We kept public content in the initial HTML

Foglift uses Next.js with server rendering and static generation for public routes. Headings, explanatory copy, internal links, FAQ answers, and JSON-LD arrive in the first HTML response. Interactive product surfaces hydrate after that content is available.

That choice helps two audit dimensions. The SEO checks can read titles, descriptions, headings, links, and schema from the response. AI-readiness checks can inspect the same answer units without waiting for a client-only application to assemble the page.

Next.js describes statically optimized pages as prerendered static HTML. That gives public pages a reliable crawlable base while preserving client-side interactivity where it is useful. The architectural rule we adopted is to reserve client code for behavior and keep the page's core evidence in server HTML.

This choice also created the largest remaining constraint. The current homepage response is 248 KB, and the Technical Audit flags it as a large HTML document. Server-rendering useful content is good. Sending every proof point, schema object, pricing detail, and demo state in one response has a cost.

4. We made accessibility a release discipline

The current audit gives Foglift.io 100 in accessibility. The result reflects many small fixes across the site: descriptive alt text for informative images, empty alt text for decorative favicons, visible keyboard focus, usable form labels, semantic landmarks, and keyboard-safe navigation and dialogs.

W3C guidance says informative images need a text alternative that conveys their essential information. It also says mouse functionality should remain available from the keyboard and keyboard focus should never become trapped. Those rules became code-review checks rather than a one-time cleanup.

Recent changes include stronger focus contrast, keyboard-accessible audit-history rows, and focus containment in mobile navigation. No single commit created the 100. The score comes from keeping those requirements intact as the interface changes.

The release rule is straightforward: if a new control cannot be identified, focused, and operated without a mouse, it is unfinished.

What did not work

A richer page template did not guarantee a higher score

In April, we built a repeatable article template with a four-column comparison table, executable code, Article, ItemList, and FAQPage JSON-LD, seven FAQs, and six to eight sources. Three successive pages using that recipe scored 88 in the former AEO model. One structurally similar page scored 90.

We published the first five-page snapshot on Indie Hackers. At that point, topic alignment, citation density, content density, and transient crawl conditions were all plausible explanations. The next full-template page joined the 88 cluster, which weakened the idea that structure alone guaranteed 90.

The lesson was valuable: a checklist can establish a floor. It cannot prove which feature caused a two-point difference unless the test isolates that feature.

Repeated polishing rarely moved the score

Foglift's audit history contains long runs of identical results. Scores tended to change after a discrete event such as removing a render-blocking resource or shipping a missing header. Copy edits and small layout changes usually left the score unchanged.

We now treat scores as step functions. A fix should map to a specific finding, the finding should disappear in the next scan, and adjacent dimensions should remain stable. Repeatedly scanning unchanged code creates more rows, not more evidence.

The 248 KB homepage is still the constraint

The latest audit reports one issue: a 248 KB HTML document. The same report shows performance at 90 and AI Readiness at 70, but its CLI output does not prove that the HTML warning caused the AI Readiness result. We keep those observations separate.

We have not solved this by hiding the warning or by trimming useful evidence blindly. The next change needs to separate above-the-fold proof from detail that can live on dedicated routes, then verify that the smaller response preserves headings, internal links, structured data, and conversion context.

Until that work ships, 248 KB remains the honest boundary of the current implementation.

The workflow we would repeat

1. Run a Technical Audit and save the report ID.
2. Pick one issue whose evidence is directly observable in HTML, headers, or markup.
3. Fix that issue at the shared layer when possible.
4. Add a regression test for the exact response contract.
5. Deploy once, then scan again.
6. Compare the issue list and category inputs before interpreting the overall score.
7. Record unresolved warnings so future work starts from evidence.

This workflow produced Foglift.io's strongest dimensions. It also exposed the 248 KB constraint and a scoring-determinism defect before we placed our own row in a public benchmark. Dogfooding works when the product is allowed to disagree with the team and when the team treats inconsistent output as a product bug.

Run the same audit on your site

Run Foglift's free Technical Audit on any public URL. It checks SEO, AI Readiness, performance, security, and accessibility, then returns the issue list behind each score. No signup is required for the audit.

Frequently asked questions

Sources and verification

1. Foglift Technical Audit, August 12, 2026, scan ff1562ca. The report returned overall 92, SEO 100, AI Readiness 70, performance 90, security 100, accessibility 100, and one 248 KB HTML warning.
2. Foglift Technical Audits, August 2, 2026, scans bb0f3001 and f7b39117. Both returned overall 92, SEO 100, AI Readiness 70, performance 90, security 100, accessibility 100, and one 247 KB HTML warning.
3. Foglift engineering release, August 10, 2026: both Technical Audit API paths detect Cloudflare, Akamai, Imperva, and generic firewall challenges before scoring, make one bounded browser-profile retry, and return an explicit access-blocked result with no page scores when the retry remains blocked.
4. Semrush, Troubleshooting Site Audit, accessed August 12, 2026. The guide documents SiteAuditBot allowlisting, the published crawler subnet, CDN handling, and Web Bot Auth signatures.
5. Sitebulb, How to Allowlist Sitebulb for Crawling, updated June 8, 2026 and accessed August 12, 2026. The guide documents IP address, custom user-agent, and custom-header access options.
6. Foglift, AI Readiness Benchmark 2026, March 16, 2026. The original cohort contained 28 tool sites; 26 scored below 100 in security and 25 were missing CSP. The benchmark was refreshed and expanded in August.
7. Foglift engineering history, March through August 2026: production header configuration, route-specific framing rules, structured-data regressions, and accessibility fixes.
8. MDN, Content Security Policy, Strict-Transport-Security, and Referrer-Policy, accessed August 1, 2026.
9. Schema.org, Article and FAQPage, accessed August 1, 2026.
10. Next.js, Automatic Static Optimization, accessed August 1, 2026.
11. W3C Web Accessibility Initiative, Images Tutorial and Accessibility Principles, accessed August 1, 2026.
12. Watson Foglift, We hit an unexplained ceiling on our own scoring tool, April 26, 2026.

Fundamentals: Learn about GEO (Generative Engine Optimization) and AEO (Answer Engine Optimization) (the two frameworks for optimizing your content for AI search engines).