Posts on Next Js.
16 posts tagged "Next Js".
The in-chapter TOC needed live JavaScript. It still got a mockup first.
The captainrandom learning hub navigation retrofit ran five phases. Every one went through the UI gate — interactive approval mockup before production code. The most interesting case was P4: the subsystem's only client-side component, with a live IntersectionObserver scroll-spy in its mockup, still approved before a line of React was written.
The backlog called it a content gap. It was navigation.
Completing an eight-chapter course on the learning hub felt like progress. Then I looked at what had actually moved the needle — track sections, prerequisite chips, and a JSON-LD breadcrumb. The backlog had been mis-filing the bottleneck for months.
The search index built in three seconds. Five phases made that possible.
Pagefind took an afternoon to wire up. The navigation phases before it took a week. A search index returns what’s there — and what needed to be there first was structure.
The cheapest phase in a seven-phase plan was also the highest-leverage one
Prerequisite chips in the learning hub — three words, one arrow, no JavaScript — outperformed every other navigation phase by the only metric that matters at the chapter level: whether a reader knows what to read first. The evidence is what the other six phases cost by comparison.
Pagefind shipped last. The prerequisite chips had already closed the harder problem.
The learning hub's navigation plan ran seven phases and ended with site-wide Pagefind search. The highest-leverage phase was five: a three-word chip at each chapter head pointing to the one thing to read first. By the time search shipped, most readers who needed it no longer did.
The read-first chip outperformed the TOC, track sections, and site-wide search
The learning hub navigation programme ran six phases across two days: track sections, a scroll-spy TOC, prerequisite chips, and site-wide Pagefind search. The smallest phase shipped fifth and delivered more navigability than all the rest combined. The structural reason was there in the spec before the build started.
Seven phases in. The chip at the chapter head was still the highest-leverage fix.
The learning hub navigation programme shipped complete last week: seven phases, P0 through P6, from breadcrumb to site-wide Pagefind search. Improving on the earlier post that identified the prerequisite chip as the spec's highest-value navigability fix — having shipped P4's IntersectionObserver scroll-spy and P6's full search index, the designation holds. Here's what shipping the full programme makes visible.
Prerequisite chips, scroll-spy TOC, and Pagefind: the trio that closed the learning hub nav spec
Seven phases of navigation work landed on the learning hub over two days. Phases P0 through P4 were infrastructure. P5 and P6 changed what the property felt like to use — and both were in the spec from day one.
The highest-leverage navigation fix was a conditional on a frontmatter field
conventions.md ranked the N1 prerequisite chip as the single highest-value navigability fix before any phase of the learning-hub navigation plan shipped. After a scroll-spy TOC, hub track sections, and site-wide Pagefind search, the ranking holds. Reader-orientation at the chapter entry-point outperforms retrieval mechanics for an audience that doesn't know what it doesn't know.
GA4 went dark for four days. Both fixes were right. One was in the wrong place.
Two PRs, each diagnosing a real fault, and GA4 still flat four days later. The problem wasn’t whether the consent signal was present — it was where in the document it lived relative to gtag.js.
Prerequisite chips were the highest-leverage fix. They shipped fifth.
The navigation spec for captainrandom’s learning hub named the N1 prerequisite chips the single highest-value browsability improvement. They shipped in Phase 5 of 7. Course sidebar, in-chapter TOC, prerequisite chips, and site-wide Pagefind each close a different kind of lost — and the order they can ship in is a dependency graph, not a priority list.
Three words and an arrow: the learning spec's highest-value navigability fix
Seven phases of navigation work shipped across the learning hub. The spec rated P5 — a row of prerequisite chips at the chapter head — highest-value for navigability. It was the only phase designed to answer a question the reader didn’t know they had.
My canonical tags were deindexing my own articles. GA4 had been right all along.
GA4 showed 2 events per seven days across a site with 70+ articles. The first instinct was broken tracking. The real cause was canonical tags instructing Google to ignore the pages meant to rank — a discovery collapse that looks identical to a measurement failure until GSC gives it away.
Eight cannibalisation pairs, one prefix strip, one PR
A numeric prefix in every calculator slug had created eight cannibalisation pairs — Google couldn't determine which URL was authoritative, so neither ranked with confidence. The fix required one atomic operation across content, routing, and the internal link graph: universal prefix strip, 23 permanent redirects, every MDX cross-link repointed. Not three PRs. One.
Eight calculators were cannibalising each other. One prefix strip fixed it in 72 hours.
A site-wide SEO audit against ukcalculator.uk surfaced 8 routes competing with themselves for the same search intent. The fix — strip the NN- prefix, issue 308 redirects across 23 routes, repoint every internal cross-link — had to land as a single atomic operation or it would introduce crawl noise between deployments. Three days later, Google had started indexing.
Google ranks URLs, not intentions: the NN- prefix strip that resolved eight cannibalisation pairs on ukcalculator.uk
A site-wide SEO audit of ukcalculator.uk surfaced eight cannibalisation pairs before a single meta-tag was touched. The common thread: a numeric sort prefix on every affected slug, one that had never been intended as a ranking signal. Fixing the URLs outweighed everything else in Phase 1.