Breadcrumbs Above the Hero, Labels From Existing Config

I was clicking through the sibling section pages of KotaPortal, the city portal I keep. On the tourism page, the hero eyebrow quietly spelled out the trail: Beranda / Pariwisata. On /kebudayaan, /olahraga, and /kepemudaan, nothing. A big slider, a big photo, and a visitor who landed mid-site with no way to see where they stood.

One page honest about its place in the tree, three shrugs.

Above the hero, not inside it

The fix for the silent pages started with a placement call. Each of those pages opens with a full-bleed HeroSlider. Squeezing the trail inside the slider meant fighting its layout on every breakpoint. So the breadcrumb went above it, in its own Container with pt-4 sm:pt-5, as the very first element on the page.

That matches the standard pattern anyway: a breadcrumb trail is a list of links to parent pages in hierarchical order, wrapped in a navigation landmark labelled with aria-label, usually placed horizontally before the main content [2]. The shared Breadcrumbs component already followed that pattern, starting with a nav element carrying aria-label="Breadcrumb".

Inside it sits an ol of li items, with a ChevronRight icon between them. The detail most copy-paste breadcrumbs get wrong is the last item. Here it renders as a span, not a link, carrying aria-current="page". The attribute marks the current item within a set of related elements, and only one element in that set may carry it [1]. Since the current page is not a link, aria-current is technically optional there. The styling already tells the story. Keeping it costs nothing and makes the state explicit.

The label was already sitting in the page

My first instinct was the wrong one: pull in a breadcrumb library, or hardcode "Beranda / Kebudayaan" strings into each page file. Both add things that never needed to exist.

The diff that fixed the three pages touched three page files, 69 added lines, and zero components. The Breadcrumbs component already existed; nothing about it changed. The label came from each page's own PILLAR config object at the top of the file.

Not a central registry. Every page defines its own PILLAR, and .name already feeds the metadata title, the icon, the settings keys, and the data fetches. The breadcrumb adds zero new strings because it reuses an object that was already doing four other jobs. One label source per page, and it predates the feature.

The fourth page, /pariwisata, stayed untouched. It already whispers its position inside the hero eyebrow. Consistency, not uniformity: every section page exposes its place in the hierarchy, but they do not need identical markup to do it.

There is a payoff beyond orientation. Google Search reads breadcrumb markup in the page body to categorize information in search results, showing where a page sits in the site hierarchy [3]. No ranking claims here, the commit added no structured data at all. The visible trail is the part that matters.

Prove it in the rendered HTML

I did not trust the diff. I checked the server-rendered HTML.

curl -s https://example.com/kebudayaan | grep -o 'aria-current="page"' | wc -l
curl -s https://example.com/kebudayaan | grep -o 'Beranda' | head -1

The first command must print exactly 1, one current-page marker in the whole document [1]. The second confirms the Beranda label survives into the rendered HTML. Last, position: the trail must appear before the HeroSlider markup, not after. If the order is flipped, Breadcrumbs ended up below the hero or got dragged inside the slider wrapper.

Sources

1. [aria-current - MDN](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-current) 2. [Breadcrumb Pattern - W3C ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/patterns/breadcrumb/) 3. [Breadcrumb structured data - Google Search Central](https://developers.google.com/search/docs/appearance/structured-data/breadcrumb)