Unchecking "Display title" on a Drupal block usually does remove the heading from the HTML entirely — but menu blocks are the loud exception, and they keep the <h2> and merely hide it from sight. Since a menu block normally renders before the page content, the result is an <h2> sitting above your <h1> in the source, invisible on screen and entirely visible to anything reading the document structure.
This page corrects two things that get repeated about this behaviour, and then explains what to actually do. Everything below was read from Drupal 11.4.6 core on disk.
What core actually does with a hidden block title
There are three distinct behaviours, not one.
Most blocks: the markup is removed
The block module's preprocess sets the label variable to an empty string whenever label_display is falsy, and the default block.html.twig wraps its heading in {% if label %}. An empty string is falsy, so the <h2> is never emitted. For a content block, a views block, a form block or almost anything else, unchecking the box genuinely deletes the heading from the page.
Menu blocks: the markup stays, hidden by CSS
Menu blocks use their own template, and that template ignores the label variable. It prints configuration.label inside an <h2> unconditionally, and when label_display is falsy it adds a visually-hidden class instead of skipping the element. The template's own docblock says why: the heading is what lets a screen reader or keyboard user jump to, or skip past, a navigation region, and it cites the W3C technique for it.
So this is not a bug and it is not an oversight. It is a deliberate accessibility decision that has a side effect on heading order.
Breadcrumbs: the heading is hardcoded and has nothing to do with the checkbox
Worth separating out, because it is often blamed on the same setting. Core's breadcrumb.html.twig contains a literal <h2 id="system-breadcrumb" class="visually-hidden">Breadcrumb</h2>. It is always there. Unchecking the breadcrumb block's title removes the block's own label; the heading inside the breadcrumb markup is untouched, because it was never a block label in the first place.
Correction: it is not display: none
The widely repeated version of this story says Drupal hides the title with display: none. It does not, and the difference is the whole point. Core's visually-hidden class positions the element absolutely, clips it to a one-pixel box and sets its width and height to one pixel. The element stays in the accessibility tree and screen readers still announce it.
display: none would do the opposite — remove it from assistive technology as well as from view — and core's own template documentation makes the same point and links the reference for it: use the visually-hidden class rather than display: none, because display: none removes the element from assistive technology too.
If the distinction between the CSS techniques is new to you, display: none versus visibility: hidden covers the mechanics and why the choice matters beyond menus.
If block titles are wrong across a whole site rather than on one page, it is usually the theme's markup and not the blocks — see Drupal theming.
So what is the actual problem?
Heading order. If your main navigation block renders before the content region — which is the normal arrangement — the document begins with an <h2> before it reaches the <h1>. Two consequences, and they are not equally serious.
- Document structure. A heading outline that opens at level two and then goes up to level one is genuinely harder to reason about with assistive technology, and it is what accessibility auditors flag.
- SEO tooling. Most automated site audits will report it as a heading-hierarchy warning. Whether search rankings themselves are affected is not something I can measure or demonstrate, and I would treat any confident claim in either direction as unverified. Fix it for the structure, not for a promised ranking change.
That distinction matters because the fix is cheap either way, and overselling the SEO half is how this topic ends up in a listicle instead of a build standard.
How to check your own site in two minutes
View the page source — not the inspector, the raw source, so you see what a crawler sees — and search for <h1. Then read upwards. Anything at <h2> or below that appears before it is a candidate. In practice you are looking for menu block titles and the breadcrumb heading.
Then decide, per heading, whether it should be present and hidden, present and visible, or absent. There is no single correct answer, and the right one depends on whether the region is a navigation landmark that benefits from a name.
What Drupal core does not give you
Core exposes one boolean per block. There is no setting anywhere for "render the label but as an <h3>", and no setting for "remove the markup on a menu block". The block plugin form has a single Display title checkbox, and the template decides the rest.
That gap is why I built the third option into the companion module for my Solo theme. With Solo Utilities enabled and the feature switched on in Solo's theme settings, the single checkbox is replaced by two selects: a visibility mode of Visible, Visually hidden (screen readers only) or Do not render at all, and a tag selector offering h1 through h6 or a plain div. Solo's block templates then honour both.
One caveat I have not solved
Solo's menu block template sets aria-labelledby on the <nav> element pointing at the heading's ID. If you choose Do not render at all on a menu block, the heading disappears but the aria-labelledby attribute stays, pointing at an element that no longer exists. On menu blocks, use Visually hidden rather than Do not render at all. Save the third option for blocks that are not navigation landmarks.
Saying that out loud is more useful than pretending the feature is complete. If you are building navigation and want the accessibility side done properly, ARIA live regions for Drupal system messages is the same kind of detail work in a different corner of the page.
Common questions
Should I just delete all the hidden headings?
No. On a navigation region the heading is doing real work for keyboard and screen reader users. Removing it to satisfy an audit tool trades a warning for a genuine accessibility regression. Change the level, or leave it alone.
Can I fix this with CSS?
No. CSS changes appearance; the heading level is in the markup. This is a template or a preprocess change.
Does this affect custom block types I created myself?
No, unless you gave them a custom template that behaves like the menu one. Content blocks go through the default block template and their labels are removed when the box is unchecked.
Is there a core issue for this?
The behaviour is intentional rather than a defect, so the framing in the queue tends to be about giving themes more control rather than about changing the default. Check the current state yourself before quoting anything — needs checking, because issue status changes and this page will not.
What to do about it
Audit the source of your homepage and one interior page, list the headings that appear before the <h1>, and decide each one deliberately. On a Solo site that is a settings change. On any other theme it is a template override, which is an hour of work and worth doing once, properly.
If your site has grown a heading structure nobody planned and you would rather have it audited and fixed than argue with a scanner, that is exactly what Drupal services is for. Send me a URL and I will tell you what is actually in your source before you commit to anything.
