Skip to content
Issue docs

Meta description wider than the 985-pixel snippet

Suggestionmeta_description_pixel_widthIssue 131

What is this issue?

This check measures how wide the page's meta description renders in a desktop search snippet and reports it when the description is wider than 985 pixels.

A snippet is laid out in pixels, not characters. Google renders it in Arial at 14px across roughly two lines, which comes to about 985 pixels of text before it is cut off with an ellipsis. Because characters are not the same width, two descriptions of identical length can sit on opposite sides of that limit.

For a page to pass this check:

  • The meta description, rendered in Arial at 14px, is 985 pixels wide or less.

Example: a 138-character description in ordinary prose renders at 856 pixels and passes. Fifty more characters of the same prose does not — and neither does the same length set in capitals.

This is advice, not a defect: it never deducts from the health score.

It is the companion to the character-length check (#69), not a replacement for it. That one reports the recommended editorial range — including descriptions that are too short — and is what a writer edits against. This one reports the width at which the snippet is actually truncated.

Why it matters

A truncated description does not affect ranking at all, and Google has been explicit that the meta description is not a ranking factor. That is why this is a suggestion and never deducts from the score. What it affects is whether the result is chosen:

  • The call to action is at the end. "…with free returns", "…book online in two minutes", "…prices from £29" is the sentence that closes the sale, and it is the first thing to disappear.
  • A sentence cut mid-word reads badly. The snippet is the only paragraph the site gets to write in the search result. Ending it on "compreh…" is a worse advertisement than ending it on a full stop.
  • Google composes its own when it does not like yours. A description that does not fit, or does not match the query, is more likely to be replaced with text lifted from the page — at which point the wording is out of the site's hands.

The character count is only an approximation of this. A description of 160 characters of narrow lower-case text fits; the same count in a wider mix does not. Measuring the width measures the thing itself.

Acting on it does not move the score. It moves the click-through rate.

How to fix it

  1. Say the important thing in the first line. Roughly the first half of the width is what survives on every result, on every device. Lead with what the page offers, not with who the company is.

  2. Cut the throat-clearing. "In this article we will look at…" and "Welcome to the official website of…" spend a quarter of the budget saying nothing.

  3. Write one sentence and one clause. A description is not a paragraph. Two short sentences almost always fit where one long one does not.

  4. Avoid capitals and long unbroken strings. Capitals are around 38% wider than lower case in Arial, and a product code or a URL in the middle of a description eats the room the sentence needed.

  5. Fix it in the template. A description generated as {Product}. {Category}. Buy online at {Brand} — {Strapline} overflows on every page it renders. Change the pattern.

  6. Check the length rule too. #69 reports the recommended 150–160 character range, including descriptions that are too short. A description can fit the width and still be too thin to earn the click.

Examples

Example 1: A description that fits

Scenario: A category page with one sentence and a clear offer.

Passes because: it renders at 856 pixels.

<meta name="description" content="Men's trail running shoes tested on wet rock and loose gravel. Free returns within 60 days, and sizing advice from people who run in them.">

Example 2: A template that concatenates everything

Scenario: A product template joins the name, the category, the brand and the company strapline.

Fails because: the sentence is cut mid-word, and every product on the site is cut in the same place.

<meta name="description" content="Trail Runner 3. Men's Trail Running Shoes. Buy online at Acme Running Company Limited — Serving runners across the United Kingdom since 1987 with expert fitting, free delivery and a sixty day no quibble returns policy on every order.">

Corrected version:

<meta name="description" content="The Trail Runner 3 in men's sizes 6–13. Free delivery and 60-day returns from Acme.">

Example 3: Fits the character count, not the width

Scenario: A 155-character description set largely in capitals.

Passes #69 — it is inside the 150–160 character range — and fails here, because capitals are around 30% wider than lower case. That disagreement is the reason both checks exist.

How PixyScan detects this

  1. Takes the meta description. The content of <meta name="description">, trimmed.

  2. Measures its rendered width. Each character is measured at Arial's own advance width — the width the font declares for that glyph — scaled to the 14px Google uses for a desktop snippet, 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 descriptions — 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.
    • Zero-width characters are measured at zero.
  3. Compares against 985 pixels. Exactly 985 passes; 986 fails.

  4. Reports the measurement. The finding carries the description, the width measured and the limit applied.

This is a measurement of the font, not of a browser, and it assumes the desktop two-line snippet. A mobile result wraps differently and shows less, so a description that fits here can still be truncated on a phone — fitting this budget is the floor, not a guarantee.

What we store

Storage Level

Page Level


Database Table / Prisma Model

PageSeoBasicsData — the description itself

audit_issues.details — the measurement


Fields Used

Field Type Description
metaDescription String The meta description, as extracted

The finding carries the measurement:

Field Type Description
metaDescription String The description that was measured
metaDescriptionPixelWidth Int The rendered width, in pixels
actual Int The measured width, structured
expectedMax Int The limit applied, 985
difference Int How many pixels over the limit

Detection Dependencies

  • HTML Document (the <meta name="description"> element)

Note

The width is derived from the description, which is stored, so it is not kept as a second column that could disagree with it after a metrics change. The finding keeps the number that was actually applied.

Further reading