Lighthouse Plus Help Guide 2026
The 10 modules that decide whether your page performs for humans and is ready for AI agents — and how Traffic Torch scores each one.
Lighthouse Plus is the human-facing half of modern web performance. Where the AEO Performance Tool measures how well AI crawlers can read your page, Lighthouse Plus measures how well real people can use it — and how ready it is for the next wave of AI agents that browse on a user's behalf.
Traffic Torch runs 10 modules against a real headless Chrome session at a mobile viewport, then explains the What, How and Why of every score. It also generates CMS-aware fix instructions so you know exactly what to change and where.
- Core Web Vitals — LCP, INP, CLS, FCP, TTFB
- Performance Score — what delays the first paint
- Accessibility — WCAG 2.2 AA, contrast, ARIA, keyboard
- Best Practices — HTTPS, console errors, deprecated APIs
- SEO On-Page — title, meta, canonical, robots, indexability
- PWA Readiness — manifest, service worker, installable
- Resource Optimisation — images, JS, CSS, fonts
- Third-Party Impact — which scripts hurt performance
- Mobile UX — tap targets, viewport, font sizes, safe-area
- Agentic Browsing — WebMCP, landmarks, form labels (beta)
Each module below includes a What, How, and Why section. The same structure powers the module explanation cards inside the Lighthouse Plus Tool, so you can jump straight to any module for a deeper understanding.
Ready to see your Lighthouse Plus score?
Get your instant 10-module Lighthouse Plus report + priority fixes + CMS-specific guidance.
No login • No tracking • 100% client-side
Powered by Traffic Torch – human-first UX, performance, and agent readiness.
Frequently Asked Questions – Lighthouse Plus
What is Lighthouse Plus? ▼
Lighthouse Plus is a human-first performance, accessibility, and agent-readiness audit. It runs 10 modules — Core Web Vitals, Performance, Accessibility, Best Practices, SEO On-Page, PWA Readiness, Resource Optimisation, Third-Party Impact, Mobile UX, and Agentic Browsing — then explains the What, How and Why of every score, with CMS-specific fix instructions.
How is Lighthouse Plus different from Google Lighthouse? ▼
Lighthouse Plus runs the same underlying headless Chrome checks, but adds three layers Google Lighthouse does not: a What/How/Why explanation for every module, CMS-aware step-by-step fix instructions generated by AI, and an Ask AI assistant that can answer follow-up questions about your specific audit.
What are Core Web Vitals? ▼
Core Web Vitals are LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift). Google uses them as a ranking signal. Lighthouse Plus also measures FCP and TTFB because they directly influence how fast content becomes visible and interactive.
How does Lighthouse Plus check accessibility? ▼
Lighthouse Plus injects axe-core into a real headless Chrome session and runs the full WCAG 2.2 A and AA ruleset against the live DOM. It captures every violation with impact level and node count, then shows fixes at the file or CMS level.
What is Agentic Browsing? ▼
Agentic Browsing is how ready the page is for AI agents that browse, fill forms, and complete tasks on behalf of a user. It checks WebMCP integration, semantic landmarks, form labels, focus order, overlay traps, and whether llms.txt and AI-friendly robots.txt are present. It is a beta module.
Does Lighthouse Plus use the PageSpeed Insights API? ▼
No. Lighthouse Plus runs all checks itself using Puppeteer and Cloudflare Browser Run. No external API is called. Every score comes from your live page.
Core Web Vitals
What is it?
Core Web Vitals are the five page-experience metrics Google uses to grade real user experience: LCP, INP, CLS, FCP, and TTFB. They measure how fast content appears, how stable it stays, and how quickly the page responds to input.
Every modern browser reports these metrics through the PerformanceObserver API. Google collects them in the field from real users through the Chrome User Experience Report, and uses them as a documented ranking signal.
Lighthouse Plus measures them in the lab at a mobile viewport, which gives you a repeatable score you can improve against. Lab and field numbers differ, but lab is the right target for engineering work — you control it directly.
Common failure patterns:
- Large unoptimised hero images that delay LCP past 4 seconds.
- Long JavaScript tasks that push INP past 500ms on interaction.
- Ads, banners, or late-loaded fonts that shift layout after first paint.
- Slow server response times that push TTFB past 800ms.
- Render-blocking CSS or fonts that delay FCP.
How it's Tested?
Traffic Torch renders your page in a real headless Chrome instance via Cloudflare Browser Run at a mobile viewport, injects PerformanceObservers before any script runs, then captures the metrics live.
- LCP: Captured from largest-contentful-paint entries during the full load plus a 3.5-second settle window.
- INP: Proxied by Total Blocking Time when no user interaction occurs — the accepted lab approximation.
- CLS: Sum of layout-shift entries excluding shifts within 500ms of user input.
- FCP: Captured from paint entries where name is first-contentful-paint.
- TTFB: Read from the browser's navigation timing API (responseStart).
Scoring thresholds (Good / Needs Improvement / Poor):
- LCP: ≤ 2500ms / ≤ 4000ms / > 4000ms
- INP: ≤ 200ms / ≤ 500ms / > 500ms
- CLS: ≤ 0.10 / ≤ 0.25 / > 0.25
- FCP: ≤ 1800ms / ≤ 3000ms / > 3000ms
- TTFB: ≤ 800ms / ≤ 1800ms / > 1800ms
Why it Matters?
Google uses Core Web Vitals as a documented ranking signal. Sites that fail them consistently lose ground in competitive SERPs and lose engagement from real users.
The business impact is larger than rankings. Studies from Google, Deloitte, and others consistently show that every 100ms improvement in load time raises conversion rates by 1-2%. A failing LCP costs you money long before it costs you rankings.
Core Web Vitals are also the foundation every other module builds on. Fixing LCP usually improves Performance Score and Resource Optimisation. Fixing CLS usually improves Mobile UX. Fixing INP usually improves Performance and Third-Party Impact. It is the module where a single fix often lifts several scores.
Core Web Vitals are the entry ticket to modern web performance. If you only fix one module, fix this one.
Performance Score
What is it?
Performance Score measures what blocks the browser from showing content quickly. It covers render-blocking resources, unused JavaScript and CSS, image delivery, main-thread work, and long tasks that freeze the page.
Where Core Web Vitals are the outcomes, Performance Score is the cause. It tells you why LCP is 3.4s or why TBT is 800ms — because a script is blocking the parser, because an image is 2MB, because the main thread is executing JS for 2 seconds before paint.
The bundle of checks mirrors Google Lighthouse's performance category, with adjustments for mobile-first rendering. Every item is something a developer can act on.
Common failure patterns:
- Synchronous scripts in <head> without defer or async.
- Large inline scripts and styles that inflate the initial HTML.
- Too many stylesheet links that block text rendering.
- Images without width/height that cause layout shift on load.
- Long tasks over 50ms that freeze the main thread.
How it's Tested?
Traffic Torch scans the raw HTML head for blocking scripts and combines that with live Puppeteer measurements of total blocking time and long tasks.
- Head script scan: Counts <script> tags in <head> without defer, async, or type="module".
- Stylesheet count: Counts <link rel="stylesheet"> tags.
- Inline script size: Counts inline <script> blocks over 500 characters.
- Inline style size: Counts inline <style> blocks over 2000 characters.
- Image attribute audit: Flags <img> without width/height or without loading="lazy" or fetchpriority="high".
- TBT and long tasks: Read live from the browser via PerformanceObserver.
Scoring:
- Blocking head script: -8 points per script (capped at -30)
- Large inline script: -10 if more than 3
- Large inline style: -5
- TBT over 600ms: -12
- Long tasks over 5: -1 each
- Images missing dimensions: -2 each (capped at -12)
Why it Matters?
Performance Score is where the most fixes live. It is the module that catches the everyday waste: 15 unused plugin scripts, an oversized hero image, a 200KB inline JSON blob in the HTML.
Fixing Performance Score almost always lifts Core Web Vitals, Resource Optimisation, and Third-Party Impact at the same time. It is the highest-leverage module in the entire audit because the fixes compound across modules.
The cost of ignoring it is cumulative. Every new plugin, every new ad tag, every new analytics integration adds weight that the original developer never anticipated. Performance Score is the friction gauge that catches this drift.
Performance Score is where the easy wins live. Most sites can move 15-25 points with a focused afternoon of work.
Ready to see what's slowing your page down?
Check Performance Score on Traffic Torch →Accessibility
What is it?
Accessibility measures WCAG 2.2 AA compliance: colour contrast, ARIA correctness, keyboard navigation, focus visibility, alt text, form labels, heading order, and landmark regions. It is the module that asks whether real people with assistive technology can actually use your page.
Roughly 15% of the world's population lives with some form of disability. That is 1.3 billion people. Many are your potential customers. Accessibility is also a legal requirement in the EU, UK, US, Canada, Australia, and increasingly everywhere else.
WCAG 2.2 AA is the international standard. It has 55 success criteria across perceivable, operable, understandable, and robust categories. Lighthouse Plus focuses on the ones automated tools can reliably check, plus a few human-judgment items that commonly slip through.
Common failure patterns:
- Low-contrast text on coloured backgrounds.
- Buttons or links with no visible focus outline.
- Images missing alt attributes or with meaningless alt text.
- Form fields without associated labels.
- Custom widgets missing ARIA roles and states.
- Heading levels that skip (H1 to H3 with no H2).
How it's Tested?
Traffic Torch injects axe-core into the live page inside Browser Run and runs the full WCAG 2.2 A + AA ruleset against the rendered DOM.
- axe-core injection: Loads axe.min.js from CDN and runs it against the rendered document.
- Rule tags: Runs wcag2a, wcag2aa, wcag21a, wcag21aa, and wcag22aa rule groups.
- Violation capture: Records every violation with id, impact level, description, help text, and affected node count.
- Fallback HTML checks: If axe fails to load, static checks for alt attributes, form field labels, and tabindex usage.
Scoring:
- Critical violation: -12 points each
- Serious violation: -8 points each
- Moderate violation: -4 points each
- Minor violation: -2 points each
- Maximum deduction capped at 100 (score floors at 0)
Why it Matters?
Accessibility is a legal requirement in most developed markets. Websites that fail WCAG 2.2 AA have been successfully sued under the ADA in the US, the Equality Act in the UK, and the European Accessibility Act. Fines and settlements are routinely in the six figures.
It is also a Google ranking signal. Google has confirmed that accessible sites tend to rank better because accessible pages are easier for their crawlers to understand. Alt text, semantic HTML, heading order, and landmark regions all help Google parse your content correctly.
The UX benefit is universal. High-contrast text, clear focus states, and labelled inputs help every user, not just those with assistive tech. Designers who build for accessibility consistently ship cleaner, faster, better-looking interfaces.
Accessibility is not a compliance checkbox. It is a UX quality signal that also happens to be the law.
Best Practices
What is it?
Best Practices measures the safe, correct, modern web fundamentals: HTTPS, no console errors, no deprecated APIs, correctly proportioned images, and no exposed framework versions. These are the checks that determine whether your page is secure, stable, and future-proof.
These are not glamorous checks. But failing them breaks things — a mixed-content request blocks images, a console error hides a broken feature, an exposed server version invites attackers, a deprecated API warns users in the browser.
Best Practices is the quality floor. Pages that fail it are visibly broken to anyone who opens DevTools, and often visibly broken to users too, even if the symptoms are subtle at first.
Common failure patterns:
- Serving over HTTP or mixed content.
- JavaScript console errors during load.
- Failed network requests for missing images or fonts.
- Use of deprecated APIs like document.write or attachEvent.
- Distorted image aspect ratios from hardcoded dimensions.
- X-Powered-By headers exposing the server stack.
How it's Tested?
Traffic Torch captures every console error and failed request during the headless render, then scans the raw HTML and response headers for the rest.
- HTTPS check: Confirms the final URL uses https://.
- Console and page error capture: Listens for console and pageerror events during render.
- Failed request capture: Records every request that fails, including the error text.
- Deprecated API scan: Grep for document.write, attachEvent, ActiveXObject, document.all.
- Image aspect ratio: Checks width/height attributes for ratio distortion (over 3:1 or under 1:3).
- Security headers: Reads response headers for HSTS, X-Content-Type-Options, and X-Powered-By.
Scoring:
- No HTTPS: -25
- Each console error: -5 (capped at -25)
- Each failed request: -3 (capped at -15)
- Each deprecated API use: -4 (capped at -15)
- Distorted images: -3 each (capped at -12)
Why it Matters?
Best Practices is the fastest way to lose user trust. A page that shows a browser security warning, blocks content with mixed-content errors, or silently fails to load a critical feature feels broken even when the content is fine.
Console errors are especially damaging because they compound. A single JavaScript error can prevent entire features from running — form validation, analytics tracking, animation, or a shopping cart. Users see a frozen button. You see nothing in analytics. The bug goes unnoticed for weeks.
Security headers are the quiet defence layer. HSTS forces HTTPS on every subsequent visit. X-Content-Type-Options prevents MIME sniffing attacks. Removing X-Powered-By denies attackers an easy fingerprint. None of these are visible to users, and all of them matter when something goes wrong.
Best Practices is the silent module. Nothing dramatic happens when it passes, and everything breaks when it fails.
SEO On-Page
What is it?
SEO On-Page covers the classic user-facing SEO checks: a unique title, a compelling meta description, a canonical link, hreflang when multilingual, correct robots directives, one H1, and a mobile viewport. These are the signals users and search engines see first, before anyone reads a word of your content.
This is not the AEO crawler layer. It is the SEO layer that affects how your page appears in SERPs, whether it can be indexed at all, and whether it will be crawled correctly across devices and languages.
Most of these checks take minutes to fix. Most sites still fail at least one. The most common by far is a noindex tag accidentally left over from staging, which quietly kills all organic traffic for the page.
Common failure patterns:
- Title under 20 or over 65 characters.
- Missing or duplicate meta description.
- No canonical link, or a canonical pointing elsewhere.
- Leftover noindex or nofollow from staging.
- Multiple H1s or no H1 at all.
- Missing viewport meta on mobile pages.
How it's Tested?
Traffic Torch parses the rendered HTML and validates each SEO on-page element against Google's documented guidelines.
- Title: Extracts <title>, checks length 50-60 chars, penalises under 20 or over 65.
- Meta description: Extracts name="description", checks length 120-160 chars.
- Canonical: Looks for <link rel="canonical"> and validates presence.
- hreflang: Counts hreflang links, notes single-locale as fine.
- Robots meta: Checks for noindex and nofollow in name="robots".
- H1 count: Counts <h1> tags, flags 0 or > 1.
- Viewport: Confirms viewport meta exists.
Scoring:
- No title: -20; too short: -8; too long: -6
- No meta description: -10; too short: -5; too long: -4
- No canonical: -10
- noindex: -30; nofollow: -10
- No H1: -12; multiple H1s: -6
- No viewport: -10
Why it Matters?
These are the visible signals in search results. A well-written title and meta description can double your click-through rate from the same ranking position. A noindex tag costs you 100% of your organic traffic for that page.
Canonical correctness decides which URL Google shows and which one it indexes. Get this wrong and you can lose all the ranking signals you have built up over years to a duplicate URL.
hreflang manages multilingual and multi-region traffic. Get this wrong and Google will show your Australian page to Canadian searchers, or serve the wrong language entirely. For international sites, this is one of the highest-impact fixes available.
SEO On-Page is the cheapest, fastest, highest-impact fix in the entire audit. Most sites can move 10-20 points in an afternoon.
PWA Readiness
What is it?
PWA Readiness measures how ready your site is to be installed as a Progressive Web App: valid manifest, registered service worker, offline fallback, correct theme colour and icon set, and HTTPS. It is the difference between a website that feels like a website and one that feels like a native app.
PWAs launch from the home screen, work offline, receive push notifications, and re-engage users without an app store. For sites that rely on repeat visits, a PWA is often a 20-40% lift in returning-user engagement.
The requirements are well defined and enforced by browsers. Chrome, Edge, and Safari all require a manifest, a service worker, and HTTPS for installability. Missing any one of them means the "Install" prompt never appears.
Common failure patterns:
- No web app manifest linked.
- Manifest missing required fields (name, icons, start_url, display).
- No service worker registration.
- Icons missing at 192px or 512px sizes.
- No theme-color meta tag.
- No apple-touch-icon for iOS installability.
How it's Tested?
Traffic Torch scans the HTML for the manifest link, service worker registration, theme-color, and icon links, then confirms the site is served over HTTPS.
- Manifest check: Looks for <link rel="manifest"> and confirms href is set.
- Service worker: Greps for serviceWorker.register or navigator.serviceWorker.
- Theme colour: Looks for name="theme-color" meta.
- Apple meta: Checks for apple-mobile-web-app-capable and apple-touch-icon links.
- Mask icon: Looks for mask-icon link (Safari pinned tab).
- HTTPS: Confirms final URL uses https://.
Scoring:
- No manifest: -25
- No service worker: -25
- No theme-colour: -8
- No apple-touch-icon: -10
- No HTTPS: -25
Why it Matters?
PWAs are the closest thing to a native app experience you can ship on the open web. They install in one tap, launch without a browser chrome, work offline, and re-engage users with push notifications. For sites with repeat visitors — news, e-commerce, SaaS dashboards — they consistently outperform regular tabs on retention.
The user-perceived speed benefit is dramatic. An installed PWA opens in under a second because the shell is cached. Compare that to a website that opens in 2-3 seconds every visit. Users feel the difference immediately.
PWAs also protect against browser-based distribution changes. When a user installs your PWA, they have a durable shortcut that survives cookie clearing, cache clearing, and browser updates. It is the most stable re-engagement channel available on the open web.
A PWA is not a nice-to-have. For repeat-visit sites, it is the highest-ROI engagement channel still available for free.
Resource Optimisation
What is it?
Resource Optimisation measures how efficiently your page ships images, JavaScript, CSS, and fonts. It tracks file sizes, modern format adoption, lazy loading, font-display strategy, and total transfer weight.
Resources dominate load time on mobile. A single 2MB hero image on a 4G connection takes 4 seconds just to download. A 500KB JavaScript bundle takes another 1-2 seconds to parse and execute. These two items alone account for most LCP failures on modern sites.
The good news is that the fixes are well understood and dramatic. Converting a PNG to WebP saves 40-60%. Enabling lazy loading on below-fold images saves another 30-50% of initial bytes. Font subsetting saves 70-90% of font payload.
Common failure patterns:
- Images over 200KB served as PNG or JPG.
- No WebP or AVIF anywhere on the page.
- Below-fold images without loading="lazy".
- Unsubsetted web fonts.
- Fonts without font-display: swap.
- Total transfer over 3MB.
How it's Tested?
Traffic Torch reads the browser's resource timing API for every asset the page fetched, groups them by type, and analyses each category against optimisation thresholds.
- Image audit: Groups by type, flags images over 200KB, checks for WebP/AVIF adoption.
- Script audit: Sums script transfer size, flags totals over 800KB.
- CSS audit: Sums stylesheet transfer size, flags totals over 150KB.
- Font audit: Counts web fonts, checks for font-display: swap in @font-face rules.
- Total transfer: Sums everything, flags over 3MB.
Scoring:
- Images over 200KB: -4 each (capped at -20)
- No modern formats with images present: -12
- Scripts over 800KB: -15
- CSS over 150KB: -10
- Fonts without font-display: -10
- Total transfer over 3MB: -12
Why it Matters?
Resource Optimisation is where the biggest performance gains live. A single image conversion can move LCP by a full second. A script reduction can move TBT by 300ms. Font subsetting can shave 100KB off the critical path.
The compounding effect matters too. Every byte you strip from the critical path shows up in FCP, LCP, INP, and TBT. Fixing resources is often the same work as fixing Core Web Vitals, just described from the asset side rather than the metric side.
It is also the module that benefits most from automation. Modern build tools convert images, subset fonts, and split bundles by default. If your build pipeline does not, adding it takes an afternoon and pays back forever.
Every byte counts. Every image converted is a millisecond earned. Resource Optimisation is where good performance actually begins.
Third-Party Impact
What is it?
Third-Party Impact measures which third-party scripts and domains hurt performance, and by how much. Tag managers, analytics, chat widgets, ads, and embeds all add CPU cost, network requests, and blocking time.
Third-party scripts are usually the largest uncontrolled cost in a page's performance budget. A single chat widget can add 200KB of JavaScript and 500ms of main-thread time. A tag manager with 15 tags can add another second. Ads can add more than everything else combined.
Most sites never measure this. The scripts get added one at a time by different departments — marketing adds analytics, sales adds chat, product adds A/B testing — and nobody audits the total cost.
Common failure patterns:
- Google Tag Manager with unused tags.
- Multiple analytics packages (GA4 + Facebook Pixel + LinkedIn + Hotjar).
- Chat widgets loaded on every page (even where nobody chats).
- A/B testing scripts running on production traffic for a finished test.
- Heavyweight embed scripts (YouTube, Vimeo, Instagram).
How it's Tested?
Traffic Torch groups every network request by origin, counts unique third-party domains, sums their transfer size and script weight, and flags known heavyweights.
- Origin grouping: Every resource is grouped by hostname; requests whose hostname differs from the page origin are marked third-party.
- Domain count: Unique third-party hosts are counted.
- Size aggregation: Total transfer and total script size from third-party origins.
- Heavyweight detection: Flags known heavy domains: googletagmanager.com, google-analytics.com, facebook.net, hotjar.com, clarity.ms, doubleclick.net, youtube.com, intercom.io, hubspot.com.
Scoring:
- Over 12 third-party domains: -30
- Over 6 domains: -18
- Over 3 domains: -8
- Third-party scripts over 500KB: -15
Why it Matters?
Third-party scripts are usually the largest uncontrolled cost in a page's performance budget. Cutting three heavy scripts often recovers more performance than weeks of internal optimisation. It is the fastest way to improve LCP, TBT, and INP at once.
The compounding risk is worse than the current cost. Third-party scripts run their own code on your page. When they have a bad deploy, your page slows down. When they are compromised, your users are at risk. When they close, the scripts break and take your page down with them.
The best practice is to load third-party scripts on interaction, not on page load. Chat widgets only need to load when the user clicks "Chat". A/B testing scripts only need to load for users in the test. Trackers can load on requestIdleCallback. This one pattern typically saves 1-2 seconds of main-thread time per page.
Every third-party script is a debt. Audit them quarterly and pay the debt down.
Ready to see which third-parties are costing you?
Check Third-Party Impact on Traffic Torch →Mobile UX
What is it?
Mobile UX measures how usable the page is on a real phone: correct viewport, readable font sizes, tap targets at least 44-48px, no forced horizontal scroll, no blocked pinch-zoom, and safe-area insets for notched devices.
Mobile is the majority of web traffic worldwide. On many sites it is 70-85% of visitors. When mobile UX fails, most of your audience feels it immediately.
These checks are the difference between a page that feels like a mobile site and one that feels like a desktop site awkwardly crammed into a small screen. Users notice tap targets that miss, text that requires pinch-zoom, and horizontal scroll that traps the viewport.
Common failure patterns:
- Viewport meta with user-scalable=no or maximum-scale=1, blocking pinch-zoom.
- Font sizes under 14px on body text.
- Buttons and links under 44px on the touch axis.
- Horizontal scroll containers users can trigger accidentally.
- Content hidden behind notches or home indicators.
How it's Tested?
Traffic Torch renders the page at a mobile viewport (390x844, deviceScaleFactor 3, touch enabled) and combines visual checks with HTML analysis.
- Viewport meta: Checks for width=device-width and absence of user-scalable=no or maximum-scale=1.
- Font size scan: Parses inline styles for font-size declarations under 14px.
- Tap target scan: Flags clickable elements with fixed width or height under 44px.
- Horizontal scroll detection: Looks for overflow-x: auto or scroll without a matching hidden parent.
- Safe-area handling: Checks for env(safe-area-inset-*) or viewport-fit=cover.
- CLS check: Flags layout shift above 0.15 as a mobile UX problem.
Scoring:
- No viewport meta: -25
- Blocks user zoom: -15 to -25
- Small fonts: -1 each (capped at -10)
- Small tap targets: -3 each (capped at -12)
- Horizontal scroll container: -8
- CLS over 0.15: -12
Why it Matters?
Mobile UX problems are the ones users complain about most, and they are the ones that hurt conversions most directly. A 40px tap target that misses costs you a sale. Font under 14px that requires zoom costs you a bounce. Horizontal scroll that traps a user costs you a session.
Google uses mobile-first indexing for almost every site now. This means the mobile version of your page is the version Google evaluates. If mobile UX is broken, your rankings reflect that even on desktop searches.
The fixes are cheap. Most mobile UX issues are one CSS change or one attribute fix. A 20-minute pass can move this module from 60 to 95 in most cases.
Mobile UX is where the user experience lives. Google sees it, users feel it, and every fix is a direct conversion win.
Agentic Browsing (beta)
What is it?
Agentic Browsing measures how ready the page is for AI agents that browse, fill forms, and complete tasks on behalf of a user. Browser copilots, task agents, and WebMCP clients need clean structure, labelled forms, and no bot walls to complete real tasks on your site.
This module is in beta because the standards are still evolving. WebMCP is a new spec for exposing tasks to AI agents. llms.txt is a new file format that describes your site to language models. The signals that matter will evolve, but the direction is clear.
What we can check today: semantic landmarks, form labels, focus order, overlay traps, stable DOM, and whether you have published the files that agents look for.
Common failure patterns:
- No llms.txt file at the root.
- robots.txt blocking GPTBot, ClaudeBot, or PerplexityBot.
- Form fields without labels or aria-label attributes.
- Missing skip-to-content link (focus order trap).
- Multiple modal overlays that could trap an agent.
- No WebMCP integration (early adopters only).
How it's Tested?
Traffic Torch checks structural signals, files agents look for, and WebMCP markers, all in the rendered DOM and the root directory of the site.
- llms.txt check: Fetches /llms.txt at the site root.
- AI crawler robot rules: Parses robots.txt for GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot.
- Semantic landmarks: Counts main, nav, header, footer, article, aside elements.
- Form field labels: Checks for id, aria-label, or aria-labelledby on inputs.
- Skip-to-content link: Greps for <a href="#main"> or similar.
- Modal/dialog density: Counts role="dialog" and modal class occurrences.
- WebMCP detection: Greps for window.__webmcp, navigator.modelContext, or webmcp markers.
Scoring:
- Fewer than 3 semantic landmarks: -15
- Unlabelled form fields over 30%: -12
- No skip-to-content link: -8
- Heavy modal density: -5 to -10
- No llms.txt: soft signal (no penalty but noted)
- AI bots blocked: -8 per bot
Why it Matters?
Agentic browsing is the next layer of the web. ChatGPT's Operator, Claude's Computer Use, Gemini's Project Mariner, and every browser copilot in development browse pages on behalf of users. When those agents can complete a task on your site, the user is one step closer to a conversion. When they cannot, they go elsewhere.
The structural requirements for agents are the same as the requirements for accessibility. Labelled forms, semantic landmarks, focus order — these are what screen readers use and what agents use. Getting agentic-ready is often the same work as getting accessible, just framed for a different audience.
This module is a bet on where the web is heading. Whether you invest now or wait depends on your audience. If you serve a younger, tech-savvy demographic, they are already using agents. If you serve an enterprise audience, you have another year before it matters.
The pages that pass Agentic Browsing today will be the ones agents can use tomorrow. This is a strategic bet on the next wave of the web.
Ready to see how agent-ready your page is?
Check Agentic Browsing on Traffic Torch →Conclusion & Next Steps – Master Lighthouse Plus in 2026
The 10 modules covered in this guide — Core Web Vitals, Performance Score, Accessibility, Best Practices, SEO On-Page, PWA Readiness, Resource Optimisation, Third-Party Impact, Mobile UX, and Agentic Browsing — form the complete framework Traffic Torch uses to evaluate human-facing page performance and agent readiness.
These modules are different from AEO Performance. AEO measures how well AI crawlers can crawl, render, parse, and extract your content. Lighthouse Plus measures how well real people can use your page, and how ready it is for the next generation of AI agents that browse on their behalf. Run both for a full picture — they cover different audiences and different signals.
Most of these modules correlate. Fixing Core Web Vitals improves Performance Score. Fixing Resource Optimisation improves both. Fixing Accessibility improves Agentic Browsing. The highest-ROI improvements tend to lift several modules at once, and a focused pass over these 10 areas can move an overall score by 20-30 points.
The Lighthouse Plus Tool gives you the diagnostic. What you do next is a matter of prioritisation: start with the lowest-scoring module, apply the recommended fix, re-audit, and watch the score move. The tool also provides CMS-specific and file-level fix instructions through the AI guidance workers, so the fix is never "figure out what to change" — it's "here is exactly what to change and where."
The sites that win the next five years will not be the ones with the most content. They will be the ones whose content is fast, accessible, and agent-ready — because that is what both humans and their AI assistants will reward.
Ready to run your full Lighthouse Plus audit?
Get your instant 10-module score + priority fixes + CMS-specific guidance. No login. No tracking. 100% client-side.
Start Free Lighthouse Plus Audit Now →Updated September 2026 – based on ongoing correlation research, headless render testing, and real-time analysis across Core Web Vitals, WCAG 2.2, PWA standards, and emerging agentic browsing specs.
