Heading Hierarchy on Squarespace 7.1 for AI Overviews

A clean DOM tree is also a clean accessibility tree. Screen readers and AI engines share a preference for one clear primary heading per page, an H2 per major section, and H3 for nested sub-points. This is not an AI-search-specific reformatting; it is a return to the heading hierarchy SEO has recommended since the early 2010s, applied to a platform that quietly stopped enforcing it.

Squarespace's own help article¹ confirms the collection-page behaviour: "On collection pages (blogs, events, portfolios), Squarespace automatically applies H1 tags to item titles. For instance, blog post titles receive H1 tags both on blog index pages and individual post pages in Version 7.1." The platform frames this as accessibility-positive and SEO-neutral, citing Google's relaxed stance on multi-H1 documents.

The framing is honest as far as it goes. Google has stated for years that multiple H1 elements are not a ranking factor. What changed between 2024 and 2026 is the rise of passage-based extraction layers — AI Overviews specifically — that read sub-sections of pages and cite them as standalone snippets. Pages with a single clear primary heading present a less ambiguous extraction surface. The change does not break Squarespace's underlying claim; it changes which behaviour is optimal.

Search Engine Land's 2026 GEO guide³ describes the pattern from the other direction: AI engines "break pages into individual passages" and choose between them based on how well each passage matches the underlying query. A page with twelve H1 elements does not break into clean passages because the heading hierarchy provides no segmentation signal — every section is equally important, which is to say none of them is.

BrightEdge's tracking through February 2026⁴ places AIO appearance on roughly 48% of monitored queries, with industry-specific coverage climbing well past 80% in education and B2B tech. The scale of the surface matters because heading hierarchy is now an editorial decision with measurable AIO consequences, not a purely accessibility-and-SEO decision with no visible downstream effect.

The view-source audit is more reliable than the editor's audit because the editor only shows you what you authored, not what the platform emits at render time. Collection item titles, for example, are tagged H1 by the platform — the editor will not surface them as H1 in its UI because they live inside the collection block. View source is the authoritative read.

 # Counts H1 elements on a live page
curl -s https://yoursite.com/blog/ | grep -oE "<h1[^>]*>" | wc -l # Expected on a clean detail page: 1 # Typical on a default 7.1 blog index: 12+ (one per visible post) 

The result tells you where to spend your editor time. Pages with one H1 are clean. Pages with two to four H1 elements usually have a designer-set H1 in a body section that the editor will let you re-tag. Collection index pages with twelve or more H1 elements need the Code Injection patch in the next section because the editor will not let you re-tag collection item titles.

Two editor-side gotchas worth flagging. First, the visual style of H2 in some 7.1 templates is much smaller than the H1 style designers were aiming for. The fix is CSS customisation in Design → Custom CSS, not reverting the tag back to H1. Second, the editor occasionally re-renders a saved page before the tag change is reflected in the live HTML; if the view-source audit still shows H1, hard-refresh and re-check before assuming the change failed.

The patch is intentionally conservative: it scopes the re-tag to collection-block H1 elements only, leaves the page's primary H1 untouched, and runs once at DOMContentLoaded with no observer overhead. Anything more aggressive risks re-tagging legitimate headings or affecting accessibility tooling.

 <!-- Heading hierarchy patch: re-tag collection item H1s as H2 --> <!-- Scope: collection blocks only. The primary H1 in the page header --> <!-- is left untouched. Tested on Squarespace 7.1 blog and portfolio. --> <script>
document.addEventListener("DOMContentLoaded", function() { const selectors = [
".blog-item-title h1", ".portfolio-grid h1", ".events-collection h1"
];
selectors.forEach(function(sel) {
document.querySelectorAll(sel).forEach(function(el) { const h2 = document.createElement("h2");
h2.innerHTML = el.innerHTML; for (const attr of el.attributes) {
h2.setAttribute(attr.name, attr.value); }
el.parentNode.replaceChild(h2, el); }); }); }); </script> 

One caveat: JavaScript-injected DOM changes are visible to Googlebot's rendering pipeline, which has supported JavaScript execution for years, but the timing is not always identical to what a human browser sees. For belt-and-braces installation on a high-traffic site, pair the JS patch with the editorial discipline of avoiding H1 tags in author-controlled blocks. The two layers compensate for each other.

Google's documentation⁵ is explicit: Googlebot is the crawler that decides Search indexing and therefore AIO eligibility. Google-Extended is a separate, training-only token that does not affect Search ranking or AIO citations. Squarespace's 26-bot AI list⁶ includes Google-Extended but not Googlebot, so toggling the AI checkbox — on or off — has no effect on whether Googlebot can read your page.

The sister cluster on AI Crawlers covers the full panel walkthrough and the 26-bot map in detail. The takeaway for this leaf: Googlebot allow-list, AI checkbox state irrelevant to AIO. With the heading hierarchy fixed and the crawler layer confirmed, the next layer is passage shape — the 134-167 word self-contained answer that lives in the passages leaf.