Most block theme SEO complaints trace back to two specific mistakes. The first is a duplicate H1: the Site Title block and the Post Title block both rendering as
h1on the same page. The second is an archive template whose Query Loop runs a custom query instead of inheriting from the URL, which quietly serves the wrong set of posts under a category or tag link. Open the Site Editor’s document outline, fix whichever block is wrongly set toh1, and switch archive templates back to “Inherit query from URL.” Both fixes take a few minutes once you know where to look.
Why it happens
The Gutenberg Site Title block renders as an h1 unconditionally, on every page type, not only the homepage. That behavior was flagged directly against WordPress core as a defect: a 2019 Gutenberg issue documented the Site Title block outputting h1 everywhere and requested conditional rendering instead, an h1 on the front page and a plain element elsewhere, matching how classic themes like Twenty Twenty already behaved. The issue was closed once a fix merged, but the underlying template pattern still reappears whenever someone manually sets both the Site Title block and the Post Title block (or a stray Heading block) to h1 in the same template. Block themes make this easy to do by accident, because heading levels are a per-block setting with no template-wide validation stopping you.
The Heading block adds a second half to the trap. By default, Gutenberg’s core Heading block does not offer h1 as the first suggested level, on the assumption that the Post Title or Page Title block already supplies the page’s one h1. Remove or hide the Post Title block from a template, and a page can end up with zero h1 elements. Leave a manually set h1 Heading block in place next to an intact Post Title block, and the page gets two. Neither failure is visible in the editor unless you check the document outline, because both render as normal-looking bold text on screen.
A third source sits in the template files themselves. A block theme only requires one template, index.html, and WordPress resolves every other template by matching the current URL against the template hierarchy: a user-edited template stored in the database first, then a child theme’s /templates folder, then the parent theme’s /templates folder. Archive-type templates (category, tag, author, date, and the generic archive template) commonly ship with a Query Loop block set to inherit the page’s query automatically. Swap that setting for a custom query, even to “improve” the layout, and the template can start showing content that does not match what the URL and title imply, which is the same duplicate-content and canonical mismatch problem covered in more detail in our canonical URL guide.
Step-by-step fix
1. Open the template in the Site Editor. Go to Appearance → Editor → Templates, and open the specific template with the problem: the front page, a single post template, or an archive template.
2. Check the document outline. Click the list-view or outline icon in the top toolbar. It shows the current heading structure top to bottom and flags skipped levels, which is the fastest way to spot a missing or duplicate h1 without reading raw HTML.
3. Select the offending block. If two blocks show as h1, decide which one should keep that level. On a single post template, the Post Title block should almost always stay h1; the Site Title block should not be.
4. Change the heading level. With a Heading block selected, use the “HTML element” dropdown in the block’s settings sidebar (or the heading-level control in the block toolbar) to move it from h1 to h2, or the reverse if the page currently has zero h1 elements.
5. Fix archive templates separately. Open each archive-type template, select the Query Loop block, and confirm “Inherit query from URL” is enabled in the block’s settings sidebar rather than a custom query source.
6. Save and preview before publishing the template change. Site Editor changes to templates apply site-wide immediately on save, so preview a live example of each affected page type first.
How to verify it worked
Reopen the document outline for each template you changed and confirm exactly one h1 appears, in the position you intended. Then check a live, published page directly: open it in a browser, use “View Page Source,” and search for <h1. You should find exactly one match. This is a more reliable check than trusting the editor preview alone, since some SEO plugins run their own on-page analysis that can miss template-level duplication if the plugin’s checker only scans the content field, not the full rendered template. If your workflow already includes a broader pre-publish check, our WordPress SEO checklist is a reasonable place to fold this heading check in as a standing step.
For the archive-template fix, confirm the category or tag page now lists the posts you expect, in the order you expect, and that the page title and the visible content agree with each other. If you also run structured data on these templates, re-validate it after the change; heading and query fixes do not usually touch schema output, but it costs little to confirm, and our schema markup guide covers how to check that separately.
What to do when the standard fix fails
If the document outline still shows a duplicate after you changed the heading level and saved, check whether a child theme is overriding the template you just edited. Because WordPress resolves templates through a fixed precedence order (database-stored user edit, then child theme, then parent theme), an edit made in the Site Editor can be shadowed by a template file still present in an active child theme’s /templates folder. Compare the two and remove or update whichever one is stale.
If the fix looks correct in the editor but the live page still shows the old structure, a caching plugin or a CDN edge cache is very likely serving a stored copy of the old template output. Purge the page cache, then the site-wide cache, and re-check with a private browser window to rule out your own browser cache.
If an archive template still shows the wrong posts after switching the Query Loop back to “Inherit query from URL,” check for a second, nested Query Loop block lower in the same template, or a plugin that filters the main query via code. Both can override the block setting you just changed. If the archive itself should not be indexed at all for a given taxonomy, that is a separate decision from fixing the query, and it belongs with your broader indexing rules rather than a template patch; see our guide to noindex mistakes for how to make that call correctly.
Frequently asked questions
Does a duplicate H1 directly hurt search rankings?
There is no verified, direct ranking penalty tied to heading structure alone. The practical risk is indirect: a confused heading structure makes it harder for search engines and assistive technology to determine what the page is actually about, and it often signals a template-level bug that affects every page using that template, not just one post.
Should every page have exactly one H1?
That is the accessible, well-supported convention, and it is what block themes assume when they hide h1 as a default option on the Heading block. Multiple sections with their own document outlines, such as an embedded widget, are a narrow exception, not the norm for standard post and page templates.
Can I just delete the Post Title block instead of changing its heading level?
Deleting it removes the page’s intended h1 entirely, which trades a duplicate-heading problem for a missing-heading problem. Change the heading level on the block that should not be h1, rather than removing a title block outright.
Do these two traps apply to classic PHP themes too?
The Query Loop trap is specific to block themes, since classic themes do not use the Query Loop block. The heading-duplication trap can occur in classic themes as well, if a theme’s header template hard-codes the site name as h1 on every page instead of only the front page, but block themes make the mistake easier to introduce because heading levels are set per block with no template-wide check.
Leave a Reply