Title wider than the 561-pixel search result
What is this issue?
This check measures how wide the page's title renders in a desktop search result and reports it when the title is wider than 561 pixels.
A search result is laid out in pixels, not characters. Google renders a desktop
result's title link in Arial at 20px, and cuts it off at roughly 561 pixels with
an ellipsis. Characters are not the same width: a capital W is more than four
times the width of a lower-case i, so two titles of identical length can sit on
opposite sides of the limit.
For a page to pass this check:
- The title, rendered in Arial at 20px, is 561 pixels wide or less.
Example: "Women's waterproof walking boots for wide feet, sizes 3-9 | Acme" renders at 583 px and is cut off. Set in capitals — "WOMEN'S WATERPROOF WALKING BOOTS FOR WIDE FEET | ACME OUTDOORS" — it is two characters shorter and renders at 776 px, a third of it invisible.
This is advice, not a defect: it never deducts from the health score.
It is the companion to the character-length check (#68), not a replacement for it. That one reports the recommended editorial range — including titles that are too short — and is what a writer edits against. This one reports the width at which the result is actually truncated.
Why it matters
A truncated title does not stop a page ranking. It ranks exactly where it would have, which is why this is reported as a suggestion and never deducts from the health score. What it costs is the click:
- The end of the title is where the differentiator usually is. "…— Free Delivery" and "…in London" and "…2026 Edition" are the parts that answer the searcher's unspoken question, and they are the first parts to disappear.
- An ellipsis reads as carelessness. A cut-off headline beside two competitors whose headlines fit is a small, repeated disadvantage across every impression.
- Google rewrites titles it does not like. A title that does not fit is more likely to be replaced with something Google composes from the page, at which point the wording is out of the site's hands entirely.
The character count is only an approximation of this. Sixty characters of narrow lower-case text fits comfortably; sixty characters of capitals does not. Measuring the width is measuring the thing itself.
Acting on it does not move the score. It moves the click-through rate.
How to fix it
Put the important words first. Whatever is at the front survives the truncation. The keyword, the product, the location — those belong before the brand and before the qualifiers.
Shorten the brand suffix, or drop it. " | Acme Running Company Limited" costs 303 pixels on every page of the site. " | Acme" costs 74.
Avoid all capitals. Capitals are around 38% wider than lower case in Arial, so a title in capitals runs out of room well over a third sooner while saying the same thing.
Cut the connective words. "The Complete Guide to Choosing the Best Running Shoes for Beginners" and "Choosing Running Shoes: A Beginner's Guide" say the same thing; the second one fits.
Fix it in the template. A pattern like
{Product} — {Category} — {Brand}produces the same overflow on every page it renders. Change the pattern, not the pages.Check the length rule too. #68 reports the recommended 50–60 character range, including titles that are too short. A title can pass this width check and still be too brief to be useful.
Examples
Example 1: A title that fits
Scenario: A blog post with the subject at the front and a short brand.
Passes because: it renders at roughly 400 pixels.
<title>Choosing running shoes for beginners | Acme</title>Example 2: A long template suffix
Scenario: A product template appends the category and the full company name.
Fails because: everything after the product name is cut off, so every product result on the site looks identical up to the ellipsis.
<title>Trail Runner 3 — Men's Trail Running Shoes — Acme Running Company Limited</title>Corrected version:
<title>Trail Runner 3 men's trail shoe | Acme</title>Example 3: Shorter in characters, wider in pixels
Scenario: A category title set in capitals.
Fails at 776 px, while the same words in sentence case are two characters LONGER and render at 583 px. Characters and pixels are not the same measurement, which is the whole reason this check exists beside the length one — and both of these are over the limit, so the real fix is to shorten the words as well.
<title>WOMEN'S WATERPROOF WALKING BOOTS FOR WIDE FEET | ACME OUTDOORS</title>Corrected version: sentence case, and the brand trimmed — 468 px.
<title>Women's waterproof walking boots, sizes 3-9 | Acme</title>How PixyScan detects this
Takes the document title. The
<title>from inside<head>, trimmed. A<title>inside an inline SVG is an icon's accessible name and is not read.Measures its rendered width. Each character is measured at Arial's own advance width — the width the font itself declares for that glyph — scaled to the 20px Google uses for a desktop result link, and the widths are added up.
- Runs of whitespace collapse to a single space first, because that is what a renderer does. A value wrapped across lines in a template is the same value and is measured as one.
- The punctuation that appears most often in titles — typographic quotes and apostrophes, en and em dashes, the ellipsis, the bullet — has its own width. Everything else outside the Latin table is measured at the width of an average letter, and combining accent marks at zero, because they are drawn on top of the character before them.
- Full-width scripts (Chinese, Japanese, Korean) are measured at a whole em each, because they are square by design.
- Zero-width characters — a soft hyphen, a zero-width space — are measured at zero, so a title padded with invisible marks is not reported as too wide for a screen.
Compares against 561 pixels. Exactly 561 passes; 562 fails.
Reports the measurement. The finding carries the title, the width measured and the limit applied.
This is a measurement of the font, not of a browser: no kerning pairs, no ligatures, no sub-pixel rounding. Those move a long string by a pixel or two, which is immaterial against a 561-pixel budget, and it is how every SERP preview tool measures.
What we store
Storage Level
Page Level
Database Table / Prisma Model
PageSeoBasicsData — the title itself
audit_issues.details — the measurement
Fields Used
| Field | Type | Description |
|---|---|---|
| title | String | The document title, as extracted |
The finding carries the measurement:
| Field | Type | Description |
|---|---|---|
| title | String | The title that was measured |
| titlePixelWidth | Int | The rendered width, in pixels |
| actual | Int | The measured width, structured |
| expectedMax | Int | The limit applied, 561 |
| difference | Int | How many pixels over the limit |
Detection Dependencies
- HTML Document (the
<title>element)
Note
The width is not stored on the page row. It is derived from the title, which is stored, so keeping it as well would create two values that can disagree after a metrics change. The finding keeps the number that was actually applied.