Ad Extras Planner

The small lines under the ad, planned on one sheet.

  • Links, callouts, lists
  • Lengths by your limits
  • Duplicate checks
A clipboard holding a blank sheet with small blank paper tabs clipped along its lower edge, on a tidy desk in soft daylight.

The guide

The Small Lines Under a Search Ad Are Wasted When Two of Them Say the Same Thing

Link titles, callouts and value lists earn their space only when each one adds something new. Checking that depends on saying exactly what the same means.

  • four things normalised before two destinations are compared, and nothing else
  • 34 of 30 the worked title, over a limit the writer chose by 4
  • 13 headers on one platform's published list, as read on 12 October 2026
  • 0 requests made by the planner when a destination is typed
Read the full guide Fold the guide 7 min · 16 sources

A search ad is a headline, a line or two of description and an address. Under it, when there is room, a few smaller lines may hang. Nobody studies them. Almost everybody glances at them.

Three kinds of extra line

Those smaller lines come in three plain shapes. The first is a link: a short title, sometimes with two lines of description beneath it, that leads somewhere other than the ad’s main address. The second is a callout, a phrase of a few words with no link at all. The third is a value list: a header such as Services, followed by the things that belong under it. Google’s developer documentation calls all of these assets, units of shareable data from which ads are built, and it notes that assets can be gathered into a set around a theme or organised by campaign. That grouping is worth copying on paper long before anything is uploaded.

The same documentation is unusually exact about sizes, and it is the one place this essay quotes a platform’s figures. As read on 12 October 2026, its reference pages give a link text of 1 to 25 characters and two description lines of 1 to 35 characters that must be set together or not at all. A callout runs from 1 to 25 characters, and a list holds 3 to 10 values of 1 to 25 characters each. The header of such a list must come from a predefined list, and the English version of that list has 13 headers, from Brands to Models.

Treat those numbers as a dated photograph. They belong to one platform, they were true on the day they were read, and they are the kind of thing that changes without notice. A planning sheet should therefore hold limits as settings, not as laws. The planner on this page starts with neutral limits of its own, offers the published figures as one labelled preset, and lets every number be changed.

One more caution about the word character. The reference pages state lengths but do not say how a character is counted, and that matters more than it sounds.

Counting what a reader sees

The Unicode annex on text segmentation separates what a computer stores from what a person perceives. Its unit is the grapheme cluster, which it glosses as a user-perceived character. An accented letter typed as a base letter plus a combining mark is one cluster. So is a family emoji assembled from four people and three invisible joiners. Count code points or storage units instead and the same line can come out several characters longer than it looks.

There is a second complication for anyone writing in Chinese, Japanese or Korean. The annex on East Asian width classes some characters as Wide or Fullwidth because, in East Asian typography, they occupy two columns where a Latin letter occupies one. Some systems charge two units for such a character. No source consulted here says which platforms do, so the planner offers both counts and makes no claim about either. Check the place where your lines will run.

Lengths are the easy part. A line that is too long announces itself. A line that repeats another one does not.

Why repeats waste the space

Whatever a platform does with these lines, the writer controls only two things: what each line says and where each link leads. Space under an ad is small. A callout that restates a link title, or a value that restates a callout, spends that space on something the reader has already been told.

Finding repeats means deciding when two texts are the same, and a naive comparison fails immediately. Free Safety Check and free safety check! differ in case and punctuation but not in what a reader takes from them. The planner therefore compares keys, not raw texts. It applies the compatibility normalization form that Unicode calls NFKC, a compatibility decomposition followed by canonical composition, so that a fullwidth letter equals its ordinary twin. It lower-cases the result. It turns every run of spaces or punctuation into one space.

That fold is deliberately modest, and its limits should be stated plainly. It does not treat a Latin a and a Cyrillic letter of the same appearance as equal, because they are different letters. It keeps accents. It does not expand a German sharp s into two letters. Above all it cannot read meaning: Open late and Late opening hours are different keys, and only a person will notice that they say the same thing. The check finds mechanical repeats and nothing subtler.

The comparison runs inside one set at a time. The same callout in a spring campaign and a winter campaign is normal, so it is not reported. Sets can be switched off without being deleted, and a set that is off is kept but not checked.

Sameness of a destination is a precise idea

Two links with different titles that lead to one page are the costliest repeat, because the reader is offered a choice that is not a choice. Catching it requires an answer to an old question: when are two addresses the same address? Comparing them letter by letter is wrong in both directions.

The standards answer part of the question firmly. RFC 3986 says the scheme and the host are case-insensitive and should be normalised to lower case. The URL Standard, which describes what browsers actually do, lower-cases the scheme as it parses and gives each special scheme a default port: 80 for http, 443 for https. A port equal to the default is dropped. Both documents remove dot segments from a path, the single dot that means here and the double dot that means one level up, and the URL Standard also recognises their percent-encoded spellings.

So the planner normalises exactly four things: scheme case, host case, a default port and dot segments. Nothing else. RFC 3986 explains the caution well when it says that comparison methods are designed to minimise false negatives while strictly avoiding false positives. A false positive here would tell you that two different pages are one.

Here is the worked example that loads with the page, for a made-up bicycle shop on the reserved documentation domain. One link is titled Book a Service and points to https://yourtown-bikes.example/service/book. Another is titled Workshop Bookings and points to https://YourTown-Bikes.example:443/service/./book. Lower-case the host, drop the default port, remove the single dot segment, and the second address becomes the first. The planner marks the pair with a D. In the same example the title Family and Children Bikes in Stock measures 34 of 30 against the neutral default limit, over by 4.

What stays different is just as important. RFC 3986 says that components other than the scheme and host are assumed to be case-sensitive, so a path that differs only in capital letters is a different destination. A trailing slash, the order of query parameters, a fragment and a leading www all leave two addresses unequal as well. Any of those pairs might reach one page on a particular server. The planner cannot know that without asking the server, and it never asks.

The query gets a table of its own. Each destination’s query is read with the browser’s URLSearchParams interface, which splits it at each ampersand and at the first equals sign of each piece. A parameter name that appears twice is reported, and so is a piece with no name, no equals sign or a broken percent escape. Which of two repeated values a reporting system keeps is not something an address can tell you, which is the reason to catch it on the sheet.

What the page leaves to you

Typing a destination causes 0 requests from the planner. The address is parsed as text and nothing more, so the only link fault the page can report is that an address does not parse. A page that has moved, a typo that still forms a valid address and a server that is down are all invisible to it. Opening each link in a browser before a campaign starts is the visitor’s job, and no worksheet should pretend otherwise.

Prices are left out on purpose. A price written into a planning document is stale the day the price changes, and a tool that invited price tables would be inviting errors. Keep prices where they are maintained.

The preview is equally restrained. It is a plain card in the system font that shows the order of the lines and where each would be cut at three widths you choose. It is not a picture of any platform’s advertisement, and a cut measured in one font will fall elsewhere in another.

The files follow open formats. The sheets are comma-separated values as RFC 4180 describes them, with quoted cells and doubled quotes. Because a spreadsheet may run a cell that begins with an equals, plus, minus or at sign as a formula, each such cell gets a leading single quote, a mitigation that the OWASP page on CSV injection lists while warning that no such guard survives every save and reopen. The full sheet is saved as JSON, the lightweight text format of RFC 8259, and read back strictly. The example shop lives on a name ending in .example, which RFC 2606 reserves for documentation.

Findings are marked with a letter in a square or a circle as well as a tone, following the accessibility guideline that colour must not be the only means of conveying information.

The discipline all this serves is small and old. Say each thing once. Send each link somewhere new. Remember that the limits belong to someone else and carry a date.

Sources

Every source consulted for this guide. Links checked October 12, 2026.

  1. URL Standard WHATWG
  2. RFC 3986: Uniform Resource Identifier (URI): Generic Syntax IETF
  3. UAX #29: Unicode Text Segmentation Unicode Consortium
  4. UAX #11: East Asian Width Unicode Consortium
  5. UAX #15: Unicode Normalization Forms Unicode Consortium
  6. RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files IETF
  7. RFC 2606: Reserved Top Level DNS Names IETF
  8. RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format IETF
  9. CSV Injection OWASP Foundation
  10. URLSearchParams MDN Web Docs
  11. Web Content Accessibility Guidelines (WCAG) 2.2 W3C
  12. Assets Google for Developers, Google Ads API
  13. SitelinkAsset Google for Developers, Google Ads API
  14. CalloutAsset Google for Developers, Google Ads API
  15. StructuredSnippetAsset Google for Developers, Google Ads API
  16. Structured Snippet Header Translations Google for Developers, Google Ads API