Fourteen Ways to Use a Summary Block

Updated September 2026 · Written and maintained by the Progression Agency strategy team

A summary block pulls items from a collection and displays them elsewhere, automatically. The test for whether to use one is simple: would you otherwise have to remember to update this by hand in three places? Fourteen genuinely useful applications are below, ordered by how often they earn their place — along with the filtering and tagging discipline they all depend on, and the empty-state failure that nobody tests for.

What is a summary block and what is it actually for?

It pulls items from a collection — blog posts, products, events, projects — and displays them somewhere else on the site, automatically, in a layout you choose.

The point is that it updates itself. Anything you would otherwise have to remember to add by hand in three places is a candidate for one, and that is the test worth applying before using it.

Fourteen genuinely useful things to do with one

Each of these solves a real problem: showing recent work without maintaining it manually, surfacing related content, or putting a collection in front of people who would not otherwise find it.

They are ordered roughly by how often they earn their place rather than by how impressive they look.

Recent work on the homepage

Pulls the newest projects automatically, so the homepage stays current without anybody editing it. This is the most reliably useful application.

Related posts at the end of an article

Keeps somebody reading rather than leaving, and it is far more effective when filtered by tag than when showing whatever is newest.

A featured selection on a service page

Filtered to work relevant to that service, so a page about one thing shows evidence of that thing rather than of everything.

Upcoming events

Pulled from an events collection so nothing has to be manually removed after it happens, which is the failure mode of hand-built event lists.

Products by category on a landing page

Where the collection is the source of truth and the landing page should never disagree with it.

Team or contributor listings

Which change more often than people expect, and are the classic example of something maintained in three places and correct in one.

Location or venue listings

Filtered by region, which also gives each location page something genuinely specific on it.

Case studies filtered by industry

So a page aimed at one sector shows work in that sector, which is far more persuasive than a general list.

Press or news mentions

Automatically current, and a page that visibly stops in 2023 is worse than no page at all.

Resources filtered by topic

Turning a flat blog archive into something navigable by subject.

A carousel of testimonials or reviews

Where those live in a collection and are genuinely attributed rather than invented.

Category landing pages built from tags

One page per tag, each showing its own filtered set, which creates real structure from an existing archive.

A ‘more in this series’ block

For multi-part content, where the sequence matters and manual linking always ends up incomplete.

A curated block using a specific tag

Where you tag the handful of items you want featured and control the selection without hard-coding it.

Which layout should a summary block use?

Grid for browsing a set, list for scanning titles, carousel for a small number, and wall where images carry the meaning.

The layout should follow what the visitor is doing. Somebody scanning for a specific article wants a list; somebody browsing work wants images.

The single-featured-item row is worth noting: if you are showing one specific thing that never changes, a summary block adds machinery for nothing and a plain block is simpler.

How does filtering actually change what it is worth?

Enormously. An unfiltered block shows whatever is newest; a filtered one shows what is relevant, and relevance is the whole value.

This is the difference between a block that keeps people reading and one that shows a service page about roofing an article about office parties.

Filter by tag or category

The most useful control available, and the reason a consistent tagging discipline is worth the effort.

Filter by author

Where contributors matter, such as multi-author blogs or team pages.

Limit the number shown

More items is not better. Three relevant items outperform twelve mixed ones.

Control the order

Newest is a default rather than a decision, and featured order frequently serves the visitor better.

Exclude the current item

So an article does not link to itself in its own related block.

Decide what happens when there is nothing

An empty block on a page is worse than no block, and this is the case nobody tests.

What is the tagging discipline this depends on?

Consistent, small and decided in advance — because filtering is only as good as the tags underneath it.

The commonest failure is an archive with forty overlapping tags applied inconsistently, which makes every filtered block unreliable and every fix laborious.

The last row is the specific failure to watch for: renaming or removing a tag empties every block filtered on it, and nothing announces that it has happened.

Do summary blocks help or hurt search visibility?

They help by creating internal links to content that would otherwise be buried, and they hurt when they are used to build thin pages that contain nothing but a block.

A page whose entire content is an automated list has almost nothing of its own to rank with, and the pattern repeated across many pages is exactly what gets discounted.

What should surround a summary block?

Enough of your own writing to explain what the collection is, who it is for, and why these items — because the block itself supplies titles and images, not meaning.

This is the difference between a useful category page and a thin one, and it costs a paragraph.

What are the common mistakes?

No filtering, too many items, no surrounding content, inconsistent tagging, and no handling of the empty state.

All five are decisions rather than technical limitations, which is why they persist on sites that are otherwise well built.

When should you not use one?

When the content genuinely never changes, when you need precise editorial control over exactly what appears, or when the collection does not really exist yet.

A summary block on a collection of three items that will never grow is machinery for nothing, and a plain hand-built block is easier to reason about.

The pattern across the yes rows is change over time. If nothing changes, automation costs complexity and returns nothing.

How do you know a summary block is doing its job?

Whether people click through it, whether the pages it links to get more traffic than before, and whether it is ever empty.

That last check takes seconds and catches the failure nobody notices: a block filtered on a tag that no longer exists, showing nothing, on a page that still looks fine.

How do summary blocks fit into site structure overall?

They are the mechanism that turns a flat archive into something navigable — but only when the pages they sit on have content of their own.

The structural question is not how many blocks to add. It is whether somebody arriving on any page can find the related thing they want without using the site search.

If the honest answer to the last row is that people mostly use search, the structure above it is not doing its job, and adding more blocks will not fix that on its own.

Frequently asked questions