Search for almost any competitive term and you'll notice something odd: the blue link rarely matches the page title you'd expect. Google has quietly rewritten it, pulling in a heading from further down the page or a phrase from the meta description instead. That single fact tells you most of what you need to know about the snippet: it isn't a caption you write once and forget, it's a negotiation between what you ask for and what Google decides will get the click.
What actually appears in a search result
A standard organic result is built from three pieces: the title (drawn from your title tag, when Google keeps it), the URL, and the meta description (drawn from your meta tag, or lifted from the page copy when Google thinks that serves the query better). Some results add a fourth element, sitelinks or a star rating or a date, depending on structured data and how the page is understood. None of this is decorative. It's the only part of your page most people ever see, because the majority of searchers never click through at all.
That last point is worth sitting with. A page can be well written, well designed, and properly structured, and still lose the click to a competitor with a sharper snippet directly above it. Ranking gets a page into the results. The snippet decides whether anyone acts on it.
Why the snippet carries more weight than it looks like it should
Two results sitting next to each other in a list of ten are being judged on almost nothing: a title, two lines of description, and a URL. There's no layout, no brand colours, no imagery to lean on. Every word is doing the work a full page would normally share across a dozen design decisions. A title should speak to the actual intent behind the search.
This is also one of the few places in a page's presentation you don't fully control. You write the tag, but the platform decides whether to honour it. That makes the snippet less like copywriting and more like a bet: you're proposing the version of the page you want shown, and the search engine either takes it or writes its own.
How truncation actually works
The most common misunderstanding is treating the cut-off point as a character count. It isn't. Titles and descriptions are truncated by pixel width, which means a title full of narrow letters, i, l, t, fits more characters before it's cut than a title full of wide ones like m and w. Two titles with an identical character count can render completely differently depending on the letters they're made of, and a title that looks fine in a spreadsheet can still get chopped mid-word on the results page.
Mobile makes this worse, because the available width shrinks and the point of truncation moves with it. A title written to fit comfortably on desktop can still lose its final clause on a phone screen, which is where a growing share of searches happen. Writing to a character limit gets you in the right neighbourhood. It doesn't guarantee the sentence survives intact.
Where the description tag gets overridden
Google will replace a meta description when it judges the page content answers the specific query better than the tag does. This tends to happen when the description is generic, keyword-stuffed, or simply doesn't match what the searcher typed. A description written once for the whole site is the most common trigger for this.
Where titles and descriptions typically go wrong
- Keyword stuffing the title: cramming in every variation of a term makes the title read as generated, and it's often the exact pattern that gets a title rewritten.
- Duplicating the same title or description across pages: templated tags across a whole site or product catalogue give the search engine nothing to differentiate on, and nothing distinctive to show a searcher either.
- Writing for the algorithm instead of the person reading the result: a title optimised purely for a ranking signal, with no sense of what someone actually wants to know, reads as hollow next to a competitor's plainer, more direct one.
- Ignoring the brand name entirely: for searches where trust matters, dropping the brand from the title removes one of the few signals a searcher uses to decide who to click.
- Front-loading the wrong word: because truncation happens from the end, the first few words carry more weight than anything that follows, and a title that opens with a filler phrase wastes the part most likely to survive.
Writing a snippet that holds up under truncation
Start from the query, not the page. What is someone actually typing when they'd want this page to appear, and does the title answer that in the first few words? A title that reads naturally at half its length is a title built the right way round.
A few habits make the difference in practice:
- Write the title so the important term sits near the start, since that's the part least likely to be cut on a narrow screen.
- Make each page's description specific to that page. A description that could sit on any page on the site is a description Google is likely to replace anyway.
- Match the description to the actual intent behind the query. It's a second chance to say something the title couldn't fit.
- Check how the same title renders on a narrower width before assuming it's finished. What looks complete in an editor can lose its last clause on a phone.
You can run your own titles and descriptions through the SERP Snippet Previewer to see roughly where they'll be cut and how they sit against the URL and description together. It's a preview built on the same pixel-width logic search engines use, not a guarantee of what will actually render: the platform can still rewrite either field if it decides its own version answers the query better than yours does.
Terms like structured data and rich results sit just outside this, and the Design Glossary is a reasonable place to check unfamiliar wording as it comes up. If snippet work is part of a wider pass on a site's technical presentation, the rest of the toolset is listed on the Design Tools page.
Treating the snippet as a design decision
Most of what makes a snippet work is the same discipline that makes any short piece of copy work: say the specific thing first, cut what isn't earning its place, and check the result at the width it will actually be read at. The difference is that here you don't get to see the final render until it's live, which is exactly why previewing it before publishing is worth the two minutes it takes.