Headings, alt text, viewport, and language tags

Why a page needs one H1, alt text on its images, a viewport tag for phones, and a lang attribute, and how to add each.

These are small parts of a page’s HTML that browsers, screen readers, and search engines rely on: the main heading, a description for each image, how the page fits a phone screen, and the language it’s written in.

Each one is a line or two of HTML. Several come from your theme or template, where one fix covers every page that uses it.

What SignalDNS checks

We fetch the page as Chrome on an Android phone would, and read up to 2 MiB of its HTML before any JavaScript runs. From it we read:

  • Headings, to count the H1s.
  • Words, leaving out scripts, styles, SVG, and frames.
  • Images: each <img>, and whether it has alt text, an empty alt="", or no alt at all.
  • The viewport tag in the head.
  • A web app manifest link and Apple’s app title tag, for saving the page to a home screen.
  • The lang attribute on the <html> element.

Anything inside <noscript> or <template> is left out, and so is a heading, image, or paragraph that a script adds after the page loads.

The page has no H1, or more than one

The H1 is the page’s main heading. It tells readers what the page is about, and screen reader users can jump straight to it. Without one, or with several competing for the top spot, it’s harder to tell what the page is about. SignalDNS marks both as needing attention, and names the first three H1s when there are several.

This is about readers, not rankings. Google’s SEO Starter Guide says there’s no ideal number of headings and that heading order doesn’t matter to Google Search. The HTML standard allows more than one H1. MDN still recommends a single H1 that describes the page, much like its title, with headings nested below it without skipping levels.

Causes include a theme that puts the site name or logo in an H1 on every page, on top of the page’s own H1, and headings chosen for their font size.

How to fix it: give the page one H1 at the top of its main content, and make the other top-level headings H2s. Style the logo with CSS instead of a heading tag.

<header>
  <a href="https://example.com/" class="logo">Example Bakery</a>
</header>
<main>
  <h1>Sourdough delivery in Portland</h1>
  <h2>How delivery works</h2>
  <h2>Prices</h2>
</main>

How many words the page has

We count the words in the HTML we received, leaving out scripts and styles. If the page is larger than 2 MiB, we count only the part we read. This is a note, never counted as a problem. Under 300 words, we call the page short.

Short is fine for a page with a simple job, such as signing in or a contact form. Google says the length of content alone doesn’t matter for ranking, and that there’s no minimum or maximum word count to aim for.

The count can be low for another reason: a page whose text is added by JavaScript looks almost empty to us, even though visitors see all of it.

How to fix it: if the page is short because it leaves questions unanswered, add what a visitor needs: what it offers, who it’s for, how it works, and what it costs. Don’t add words only to reach a number.

Images are missing alt text

The alt attribute describes an image in words. Screen readers read it out, browsers show it when the image doesn’t load, and Google uses it, along with the image itself and the page around it, to understand what the image shows. When alt is missing entirely, some screen readers read out the file name instead.

We sort each image into one of three groups: with alt text, decorative (alt=""), or without an alt attribute. If fewer than 90% have alt text or are marked decorative, SignalDNS marks it as needing attention, and Details lists up to 20 of the images without one.

An empty alt="" counts as described, because it’s the right choice for an image that adds nothing, such as a divider or a background flourish. It tells screen readers to skip the image. Leaving out alt doesn’t.

How to fix it: describe what each image shows, in the context of the page, in a short phrase. For an image that’s a link, describe where the link goes. Give decorative images an empty alt. Don’t fill alt text with keywords; Google’s image guide warns that it can make a site look like spam.

<img src="/images/loaf.jpg" alt="Sourdough loaf cut open to show the crumb">
<a href="https://example.com/order"><img src="/images/order.png" alt="Order bread"></a>
<img src="/images/divider.svg" alt="">

The page has no viewport tag

Without a viewport tag, phone browsers lay the page out as if the screen were much wider, then shrink it to fit. MDN gives the example of a 980-pixel layout squeezed onto a 640-pixel screen. Text comes out tiny, and people have to zoom and scroll sideways. Google indexes and ranks the version of a page its smartphone crawler sees, so that’s the version that counts.

SignalDNS marks two cases as needing attention: no <meta name="viewport"> at all, and one that doesn’t set width=device-width, such as width=1024, which keeps the wide layout.

How to fix it: add this to the <head> of every page:

<meta name="viewport" content="width=device-width, initial-scale=1">

Leave out user-scalable=no and maximum-scale=1, which stop people zooming in. MDN warns that turning off zoom stops people with low vision from reading the page, and that WCAG requires text to scale to at least twice its size. The tag lets your CSS fit the screen; the layout itself still needs to adapt to narrow widths.

Saving the page to a phone’s home screen

When someone adds a page to their home screen or installs it as an app, the phone needs a name and an icon for it. A web app manifest provides them: a JSON file, linked from the page, with the app’s name, a shorter name, icons, colors, and how it opens.

This is a note, not a judgment. We show “Web app manifest” when the page links one, the title from Apple’s apple-mobile-web-app-title tag when it has that instead, and “No manifest” otherwise. Neither is required, and neither affects search. We only see the link, so we don’t open the manifest or check what’s in it.

<link rel="manifest" href="/manifest.webmanifest">

{
  "name": "Example Bakery",
  "short_name": "Bakery",
  "start_url": "/",
  "display": "standalone",
  "icons": [{ "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }]
}

Apple’s older guide says iOS names a home screen icon after the page’s <title> unless apple-mobile-web-app-title sets another name. web.dev advises using the manifest instead of Apple’s older meta tags, such as apple-mobile-web-app-capable. For the small icon in browser tabs and search results, see favicons.

The page doesn’t declare its language

The lang attribute on <html> says which language the page is written in. Screen readers use it to choose the right pronunciation, and WCAG 3.1.1 requires the page’s language to be stated in the code, not left for software to guess. SignalDNS marks a missing or empty lang as needing attention.

Google says it doesn’t use lang to work out a page’s language; it reads the visible text. So this is about accessibility, not search. We also use lang to decide whether to run the checks that only work for English, such as the title agreement and answer readiness checks.

We read only the lang attribute on the <html> element. A Content-Language header or meta tag doesn’t count.

How to fix it: set it on the <html> element, with a language tag such as en, en-GB, fr, or pt-BR:

<html lang="en">

Mark any passage in another language with its own lang, such as <p lang="fr">. To link a page’s versions in other languages, use hreflang.

Setting it up in your CMS or framework

What we can’t tell from outside

We read the HTML before scripts run, so a page built in the browser can look as if it has no headings, words, or images. We check that alt text exists, not whether it’s accurate. We don’t render the page, so we can’t see whether the layout actually fits a phone, only whether the viewport tag asks it to. We don’t open the manifest, and we don’t check that lang matches the language the page is written in.

Sources

Last reviewed .