Write article titles and links that help people browse
Make article lists easier to scan with specific titles, front-loaded summaries, descriptive section headings, and links that name their destinations.
Start an article title with its concrete subject, state the useful distinction in the rest of the title, and let the summary explain what the reader will learn. Use headings that still make sense in a list and link text that names the destination.
A library shelf is easier to browse when the book spines say what the books contain. A row of labels saying 'Read more' is like a shelf where every spine has the same title.
An article catalogue can have perfect search and still feel hard to explore. Readers arrive with a half-formed question, glance over several cards, and decide which one deserves a click. If the titles hide the subject and every card ends in “Read more,” the page makes them open articles just to discover what the articles are about.
The article card is a promise#
A useful card answers three different questions quickly. The title: What is this about? The summary: What will I understand or be able to do? The link: Where will this take me? Repeating a vague benefit in all three places gives the reader very little evidence for choosing the page.
For a technical article, “Everything you need to know about databases” makes a large promise but gives no boundary. “B-tree vs LSM tree: how writes and reads differ” names two concrete subjects and the comparison the page will make. The narrower promise is more useful when it matches the actual article.
Put the subject first#
On a crowded browse page, readers may see only the first words before deciding whether to keep scanning. Lead with the concept, task, or contrast they are looking for. Move the clever turn of phrase, background, or brand voice later if it still helps.
| Harder to scan | Clearer promise | Why |
|---|---|---|
| When your data stops fitting | Database sharding: when one database is no longer enough | The concept appears immediately. |
| A tale of two queues | Queue vs topic: choosing a delivery model | The comparison is explicit. |
| Getting started with something faster | Binary search: a worked example on sorted data | The method and prerequisite are visible. |
A summary should add information, not restate the title. After “Queue vs topic: choosing a delivery model,” a useful summary might say that the article follows one message through each model and shows when multiple consumers receive it. That tells a reader whether the page answers their question. Avoid promising a live tool, benchmark, or downloadable template unless the page actually contains one.
Headings should work alone#
The same problem continues after a click. A reader may scan the table of contents before committing to the full article. “Overview,” “Details,” and “Considerations” describe the writer’s outline, not the questions the reader can answer. “What gets stored in an index?”, “What a write costs,” and “When the index is the wrong choice” convey a path through the topic even outside the body text.
This also matters when headings are read as a list by assistive technology. A heading should carry enough context to be useful without the paragraph above it. It need not be long; it needs to identify the idea, action, or distinction in that section.
Name the link destination#
A page of repeated “Read more” links forces people to infer every destination from surrounding text. It is even less useful when the links are listed separately by a screen reader. Often the cleanest solution is to make the card’s specific title the link. When a separate link makes sense, describe the action or page: “Compare B-trees and LSM trees” tells a reader far more than “Learn more.”
Links inside an article deserve the same care. “See our guide to distributed tracing” carries its destination in the linked words. “Click here” adds no information and assumes a mouse, even though readers may use touch, a keyboard, or voice controls. The link should still be visually distinguishable so people can recognize it as interactive.
A five-minute editing pass#
Print or copy a browse page’s titles without summaries. Can you tell which question each article answers? Now read the summaries without titles. Do they add a concrete method, example, or boundary? Finally, list the link texts alone. If several entries are identical or vague, link the titles or rewrite the action labels.
Apply the same test to the article’s headings. If the table of contents reads like a sequence of placeholders, revise the headings after the body is finished. That gives each heading a real claim to make. A short article with specific signposts is usually easier to browse than a longer article with a more elaborate but less informative introduction.
Once the labels invite the right click, make the article comfortable to read. You can compare the labels in the full article library to see how they behave in a real list.
The next step is to handle the moment when those labels still produce no match: design a useful empty search state.
IF YOU REMEMBER ONE THING
Let a reader decide what to open from the title and summary, then find the relevant part from the headings alone.
Questions people also ask
3 QUESTIONSShould every article title begin with a keyword?
Begin with the subject people need to recognize, in natural language. A title should say what the page actually covers; a forced keyword list makes browsing harder.
Can a card title be the link instead of adding a Read more link?
Yes. Linking the specific title often makes the destination clear. If a separate link is needed, its visible text should explain the destination or action.
How specific should section headings be?
Specific enough that the heading makes sense in a table of contents or screen-reader heading list. Name the question answered or the distinction made, rather than using a generic label such as Details.