--- title: "Marketing Hygiene Matters but Can People and Search Agents Read Your Website?" date: 2026-08-11 author: "warrenlainenaida" featured_image: "https://warrenlainenaida.net/wp-content/uploads/2026/08/warren-laine-naida-greengeeks-webinar-ai-accessible.webp" categories: - name: "Accessibility - an Accessible Website is a Useful Website" url: "/category/accessibility.md" - name: "Artificial Intelligence and Online Marketing" url: "/category/artificial-intelligence-online-marketing.md" - name: "Search Engine Optimisation - Get Yourself Found!" url: "/category/seo.md" - name: "Sustainability - Maintain and Improve Your Marketing!" url: "/category/sustainability.md" - name: "Teaching & Learning - Collaborative Exploration Leads to Growth!" url: "/category/teaching-and-learning.md" --- # Marketing Hygiene Matters but Can People and Search Agents Read Your Website? ## A GreenGeeks Webinar with Warren Laine-Naida **Another Free GreenGeeks webinar! How site accessibility drives AI-readability and SEO together – plus quick audit steps to cut your carbon footprint.** *AI agents ([and they are just one of five groups accessing your website](#website-agents)) don’t browse your website like a human does; they parse it.* A cluttered, JavaScript-heavy site that’s hard on screen readers is often just as hard on the bots now reading, ranking, and recommending it. This session breaks down why accessibility, SEO, and AI-readability have quietly become the same job – and what that means for your site’s real carbon footprint. Hashtag GEOAccessibility. ### What You’ll Learn in this Webinar: - Why Accessible Sites Are the Sites AI Agents Actually Understand - The Hidden Carbon Cost of Bloated, JavaScript-Heavy Pages - Quick Audit Steps to Improve Rankings, Access, and AI Visibility Together ### Other GreenGeek Webinars with Warren See all of the GreenGeeks Webinars right here: [![](https://warrenlainenaida.net/wp-content/uploads/2026/08/Mastering-Social-Media-Advertising_Warren-Laine-Naida_Webinar_ok-1024x536-1.jpg)](https://www.greengeeks.com/webinars/mastering-social-media) [![](https://warrenlainenaida.net/wp-content/uploads/2026/08/Getting-the-Most-Out-of-AI_Warren-Laine-Naida_Webinar-1024x536-1.jpg)](https://www.greengeeks.com/webinars/ai-for-marketing) [![](https://warrenlainenaida.net/wp-content/uploads/2026/08/Marketing-Hygiene_Warren-Laine-Naida_Webinar-1024x536-1.jpg)](https://www.greengeeks.com/webinars/marketing-hygiene-and-sustainable-practices) ## Who or What is Accessing my Website? **Search bots (crawlers), people, screen readers, AI/LLM crawlers, and AI agents all access websites very differently.** They request pages over HTTP, but what they receive, how they process it, what they prioritize, and what they do with the result diverge sharply. A site that is hard for one is often hard for others – especially cluttered, heavily JavaScript-dependent pages with poor semantic structure. ### 1. Traditional search engine bots / crawlers (e.g., Googlebot, Bingbot) These are automated programs whose main job is **discovery → fetch → render (sometimes) → parse → index**. - **Discovery**: They find URLs via links from other pages, sitemaps, Search Console submissions, and previous crawls. - **Fetch**: They send HTTP requests (respecting robots.txt for most reputable ones). Googlebot currently fetches up to ~2 MB of the response for most files (higher for PDFs). They check status codes, headers, and content. - **Rendering**: Modern Googlebot uses a headless Chrome-like renderer (Web Rendering Service). It executes JavaScript and CSS so it can see content that only appears after client-side rendering. Many other crawlers (and most AI training crawlers) do **not** render JavaScript fully or at all. - **Parsing & indexing**: They extract text, links, structured data (JSON-LD, microdata), headings, titles, meta descriptions, images (with alt text), etc. The goal is to build a searchable index for ranking and retrieval. - **Behavior traits**: Polite rate limiting (crawl budget), follow robots.txt and meta robots directives, prefer mobile-first crawling in many cases, recrawl based on importance and change frequency. They do not interact like users (no form filling, no purchases, no prolonged sessions). Other bots exist for images, video, ads, shopping, news, etc., each with specialized behavior. ### 2. People (human users) Humans experience the **rendered visual + interactive page** through a full browser. - They load the page (HTML + CSS + JS + images + fonts + media). - The browser builds the DOM, applies styles, runs scripts, and paints the visual layout. - Users see design, colors, layout, images, animations, and interactive elements. They scroll, click, hover, type, fill forms, watch videos, and navigate by visual cues, muscle memory, and intent. - They rely on visual hierarchy, branding, trust signals, and usability. Content that is buried behind clicks, tabs, infinite scroll, or heavy JS may still be reachable if the interface is clear. - Analytics, cookies, personalization, and A/B tests are typically designed around human sessions. Humans are the original audience most sites are optimized for, but they are no longer the majority of traffic on many sites. ### 3. Screen readers (and other assistive technologies) Screen readers (NVDA, JAWS, VoiceOver, TalkBack, etc.) convert the page into speech or braille for people who are blind or have low vision. They do **not** “see” the visual design. - Browsers build an **accessibility tree** from the DOM. This tree exposes roles (button, heading, link, landmark), names, states (checked, expanded, disabled), relationships, and properties. - Semantic HTML (<h1>–<h6>, <nav>, <main>, <button>, proper form labels, alt text, ARIA where needed) is critical. Decorative images should be ignored; interactive elements need clear names and states. - Users navigate by keyboard shortcuts: headings (H key), landmarks, links, form fields, lists, etc. They often move linearly or jump by structure rather than visual position. - Poor semantics, missing labels, inaccessible custom components, or content only present after complex JS interactions make the page unusable or exhausting. - Screen readers operate on the accessibility tree (and sometimes DOM details). Visual clutter, missing structure, or non-semantic markup that confuses the tree also confuses them. This is why accessibility and clean markup matter so much: the same issues that hurt screen-reader users often hurt automated parsers. ### 4. AI/LLM crawlers and training bots (e.g., GPTBot, ClaudeBot, PerplexityBot, Common Crawl variants, Google-Extended) These primarily **collect content** for model training, retrieval-augmented generation (RAG), or grounding answers in search/chat products. - Many perform simple HTTP fetches of the initial HTML and do **not** fully execute JavaScript the way Googlebot does. Client-side-only content is frequently invisible. - They extract text, structure, and sometimes other assets. Some convert pages to cleaner formats (markdown-like) for token efficiency. - They often check robots.txt (though enforcement and respect vary) and may look for emerging signals such as /llms.txt (a curated, token-efficient site summary for AI systems). - Goals differ from classic search: bulk text for training data, fresh content for answer engines, or citations. They may prioritize different content types and have different politeness or blocking behaviors. - Result: a JavaScript-heavy single-page app that shows almost nothing in the initial HTML is often poorly understood or ignored by many of these bots. ### 5. AI agents (agentic systems, browser-using LLMs, task-oriented agents) This is the newest and most varied category. Agents act on behalf of a user to achieve goals (research, compare products, fill forms, book something, extract structured info, etc.). They access sites in several ways, often hybrid: - **Raw HTTP + HTML/markdown parsing**: Fast, cheap, no JS execution. Good when the server sends meaningful content. Many agents try this first. - **Headless browser / full rendering**: They load the page like a browser, execute JS, and then work with the rendered DOM, accessibility tree, or both. Some also take screenshots and use vision models. - **Accessibility tree + DOM reading**: Increasingly common. The accessibility tree (the same structure screen readers use) gives roles, names, and interactive elements cleanly and with far fewer tokens than the full DOM or a screenshot. Agents can identify buttons, forms, and content structure more reliably this way. - **Vision / screenshot-based**: Some systems (or modes) capture the visual page and reason about pixels + text. This is more expensive and error-prone for precise interaction but handles visual-only cues. - **Interaction**: Unlike pure crawlers, agents can click, type, scroll, submit forms, handle multi-step flows, and adapt. They plan, observe, act, and re-observe. - **Discovery aids**: robots.txt, sitemaps, /llms.txt, structured data, APIs, and emerging protocols (MCP-style tool exposure, content negotiation for markdown, etc.) help agents find and use content efficiently. Because many agents lean on the accessibility tree or clean semantic HTML, sites that are inaccessible to screen readers are frequently also hard for agents. Heavy client-side rendering without server-rendered fallbacks, missing labels, non-semantic custom UI, and anti-bot challenges that block automated browsers all create friction. ### How they relate (and why the opening quote is accurate) - **People** experience the full visual + interactive result. - **Screen readers** experience a linearized, semantic, structured version via the accessibility tree. - **Search bots** (especially Google) try to approximate the rendered page for indexing, with resource and size limits. - **AI crawlers** often get a more limited, text-focused view and frequently skip full JS rendering. - **AI agents** sit between crawlers and users: they may render and interact, but they still rely heavily on parseable structure, semantics, and the accessibility tree. Cluttered markup, missing semantics, or content that only appears after heavy client-side work hurts them the same way it hurts screen readers and many bots. ### Practical Website Hygiene for site owners What is hard for screen readers and traditional crawlers is usually hard for the new generation of AI agents and LLM systems as well. - clean, semantic HTML - proper headings and landmarks - meaningful alt text and labels - server-rendered or progressively enhanced content - structured data - a sensible robots.txt - and emerging AI-friendly signals (sitemaps, llms.txt, clear APIs) Everything that accesses your site – humans, assistive tech, search crawlers, training bots, and autonomous agents – ultimately depends on the HTTP response and the structure you expose. Optimizing for clarity and semantics benefits the whole spectrum. ## Core thesis: Accessibility = AI-readability = SEO Multiple 2026 sources now confirm our core point: *AI agents don’t “browse” like humans; they parse structured, semantic layers of your site – the same layers screen readers use.* In practice, that means: - **Accessible sites are the sites AI agents actually understand.** AI agents (ChatGPT Atlas, Perplexity, Claude, etc.) rely on the browser’s accessibility tree built from semantic HTML, headings, ARIA, landmarks, and form labels. - **Cluttered, JavaScript‑heavy pages hurt both humans and bots.** Heavy client‑side rendering, unlabelled interactive elements, and skipped heading levels make content harder to extract for LLMs and screen readers alike. - **The same fixes improve rankings, access, and AI visibility together.** Clean semantic structure, proper labels, and stable DOMs help traditional SEO, accessibility compliance, and Generative Engine Optimization (GEO/AEO) simultaneously. ## Why accessible sites are AI‑friendly - **AI agents read the accessibility tree, not your visual design.** OpenAI and other vendors confirm agents navigate via the structured semantic layer exposed to assistive tech. - **Screen‑reader‑friendly markup is LLM‑friendly markup.** Alt text, heading hierarchy, landmark roles, and descriptive link text give unambiguous signals about what content is and where it belongs. - **Sites that fail accessibility checks see lower agent task completion.** Research shows agents complete more tasks on sites passing contrast, label uniqueness, and keyboard reachability checks. ## The hidden carbon cost of bloated, JS‑heavy pages - **JavaScript costs twice:** transfer energy plus device execution energy. Cutting JS reduces emissions across the whole chain and speeds up pages. - **Client‑side energy can be 2–5× higher** for JS‑heavy SPAs vs server‑rendered HTML per page view. - **Page weight drives CO₂.** A 5MB page generates roughly 5× the carbon of a 1MB page; long JS execution times increase client‑side energy use. - **Typical breakdown:** ~80% media, ~15% JavaScript, ~5% server code for many pages – so trimming JS and media yields the biggest carbon gains. - **Framework choice matters.** Astro emits ~0.005g CO₂/page vs React ~0.015–0.025g and Angular up to ~10× Astro per page view. ## Quick audit steps to improve rankings, access, and AI visibility - Use this short checklist on your top 5 pages (home, main service/product, pricing, contact/booking, top landing page). - [No time to read? Download the One Page Checklist PDF.](https://warrenlainenaida.net/wp-content/uploads/2026/08/AI-Ready_Accessible_Site_Audit_Checklist.pdf) ### Run an accessibility tree audit (10 minutes/page) - In Chrome DevTools: Elements → Accessibility tab. - Verify: - One H1 that matches page intent; no skipped heading levels (H1→H2→H3). - Landmarks present: header, nav, main, footer (and aside if used). - All interactive elements (buttons, links, icons, form fields) have descriptive labels or aria‑labels. - Alt text on meaningful images; decorative images marked appropriately. - Link text is descriptive (avoid “click here”). ### Check rendering mode and JS weight - Use Lighthouse (Chrome DevTools) to identify: - Unused JavaScript and large bundles. - Opportunities for server‑side rendering or static generation to reduce client execution. - Targets often cited in 2026 guidance: - Initial JS bundle under 150–200KB (gzipped). - Page weight under 1MB where possible. ### Add/validate structured data and agent signals - Implement JSON‑LD for key entities: Organization/LocalBusiness, Product/Service, FAQPage, Article as relevant. - Consider an `ai-agent.json` manifest at `/.well-known/` to guide agents to critical pages. - Segment `robots.txt` for training crawlers vs search bots vs agents if you have specific policies. ### Measure carbon and set a budget - Run a quick grams‑per‑view estimate with a website carbon calculator, then refine with Lighthouse byte‑weight and unused JS reports. - Adopt a target such as 0.5g CO₂ per page view (Sustainable Web Design model) and monitor quarterly. ### Prioritize fixes that move multiple needles Focus first on: - Heading hierarchy and landmark roles (SEO + a11y + AI parsing). - Form labels and button semantics (agent task completion + WCAG). - Removing unused JS and third‑party tags (speed + carbon + crawl efficiency). ## Useful references and further reading - **AI agents and the accessibility tree:** WebKing (2026) explains why agents read your accessibility tree, not your design, with concrete markup checks. [webking](https://www.webking.com/lab/why-ai-search-agents-read-your-accessibility-tree-not-your-design) - **Accessibility as an SEO/AEO signal:** Accessibility.works (2026) frames WCAG compliance as the foundation for GEO/AIO/LLMO. [accessibility](https://www.accessibility.works/blog/value-of-accessibility-compliance-for-aeo-in-agentic-web-era/) - **Carbon of JavaScript frameworks:** Should I Use This Framework (2026) provides CO₂/page data by framework and optimization guidance. [shouldiusethisframework](https://shouldiusethisframework.com/blog/framework-carbon-footprint-2026) - **Sustainable Web Design targets:** SiteGrade and related 2026 guides outline 0.5g/page targets and practical reduction tactics. [sitegrade](https://sitegrade.io/en/blog/green-web-carbon-footprint-website/) - **Warren Laine‑Naida on accessible SEO and AI:** Podcast episodes and talks emphasize “good HTML, clear headings, structured content” as the core of AI‑optimized SEO. [stunningdigitalmarketing](https://stunningdigitalmarketing.com/episode-473-seo-with-warren-laine-naida-how-seo-is-impacted-by-ai/) > [Making a WordPress Site Agent-Ready: A Practical Tutorial](https://warrenlainenaida.net/making-a-wordpress-site-agent-ready-a-practical-tutorial/) > [Clean SEO Marketing for Improved AI Search](https://warrenlainenaida.net/clean-seo-marketing-for-improved-ai-search/)