Skip to content
Issue docs

More than one title tag in the head

Standardmultiple_title_tagsIssue 133

What is this issue?

This check counts the <title> elements in the page's <head> and reports the page when there is more than one.

HTML allows exactly one. The browser and the search engine both keep the first and ignore everything after it, so a second <title> is not an alternative — it is dead markup that happens to look authoritative.

For a page to pass this check:

  • The <head> declares exactly one <title>.

Example: a head containing <title>Running shoes</title> passes. A head containing that plus <title>Acme — Running shoes for every distance</title> fails, and the second, better-written title is the one nobody will ever see.

A <title> inside an inline <svg> is not counted. That is an icon's accessible name, and every icon on the page has one; counting them would report any page with two icons.

This is not the duplicate-title check (#66). That one is about two different pages carrying the same title. This one is about one page carrying two.

Why it matters

Nothing breaks. The page is crawled, indexed and ranked exactly as it would be with one title, which is why this is graded STANDARD rather than higher.

What goes wrong is quieter and more expensive to find:

  • The title being used is not the title being edited. Two tags almost always mean two writers — a theme and an SEO plugin, a layout and a page template, a server render and a client-side injection. Somebody changes the one they can find, deploys, and nothing happens in the search result. That is a debugging session, repeated.
  • Which one wins depends on document order, not intent. Move a partial in the layout and the live title changes with no edit to any title.
  • It is a symptom of two systems writing one head. Where there are two titles there are usually two canonicals, two descriptions and two sets of Open Graph tags, each with the same ambiguity.

The fix is cheap — delete one line, from whichever of the two writers should not have been writing it — and the page is better for it. Cheap fix, indirect effect: that is what STANDARD means.

How to fix it

  1. Find both writers. View the page source and search for <title. The two tags are usually far apart: one in the base layout, one injected by a plugin, a template partial or a head-management library.

  2. Pick the one that should own it. Whichever system knows the most about the page — usually the page template or the SEO module, not the base layout — keeps the tag. The other stops emitting one.

  3. Give the layout a fallback, not a duplicate. A base layout should render a title only when the page did not supply one. Most head-management libraries do this by default; the bug is usually a hard-coded <title> sitting beside the dynamic one.

  4. Check the rest of the head while you are there. Two titles usually travel with two descriptions and two canonicals from the same pair of writers.

  5. Do not "fix" an SVG title. <svg><title>Search</title></svg> is correct and accessible markup. It is not counted here and must not be removed.

Examples

Example 1: A layout and a plugin both writing the head

Scenario: The base layout hard-codes a title; the SEO module injects the real one below it.

Fails because: the head declares two, and the hard-coded one wins.

<head>
  <title>Acme</title>
  <title>Trail Runner 3 men's trail shoe | Acme</title>
</head>

Corrected version: the layout renders a title only as a fallback.

<head>
  <title>Trail Runner 3 men's trail shoe | Acme</title>
</head>

Example 2: Icons, which are not a problem

Scenario: A page with two inline SVG icons, each with an accessible name.

Passes. Only <title> elements directly inside <head> are counted; the SVG ones are the icons' names and are correct markup.

<head><title>Search results</title></head>
<body>
  <svg><title>Search</title>…</svg>
  <svg><title>Close</title>…</svg>
</body>

Example 3: Three titles from three sources

Scenario: A migration left the old theme's title in place alongside the new template's and a client-side injection.

Fails, and the finding names the count and the winner, so the first question — "which one is live?" — is answered on the row.

<head>
  <title>Home</title>
  <title>Women's walking boots | Acme</title>
  <title>Acme Running Company</title>
</head>

How PixyScan detects this

  1. Counts the title elements in the head. Only <title> elements that are direct children of <head> are counted. This scoping is deliberate and it matters: a <title> inside an inline <svg> is the accessible name of an icon, and icon sprites are everywhere. A count that included them reported "duplicate titles" on any page with two icons.

  2. Reports when the count is above one. A head with no title at all is the missing-title check's business, not this one's.

  3. Reports which title wins. The finding carries the count and the text of the first <title> — the one a browser and a search engine will actually use — so the row answers "which of them is live" without opening the page.

The same measurement is stored on the page's record, so the page report can show every element the page declares more than once, whether or not a finding was raised for it.

What we store

Storage Level

Page Level


Database Table / Prisma Model

PageSeoBasicsData — the measurement

audit_issues.details — the finding


Fields Used

Field Type Description
title String The first title in the head — the one that is used
hasDuplicateElements Boolean Whether the page declares any head element more than once
duplicateElements Json Each repeated element, with the winning value and the count

The finding carries:

Field Type Description
count Int How many title elements the head declares
title String The first one — the title that is actually used

Detection Dependencies

  • HTML Document (the <head> element)

Note

duplicateElements also records repeated canonicals and H1s. Those are measured and shown on the page report but have no catalogue check of their own, so no finding is raised for them.

Further reading