The Launch Passed QA Because QA Never Asked Where the Links Went

Six days after an engineer called a store launch clean, the shop administrator messaged at 8:17 on a Tuesday to ask why the best-selling product had vanished from search ^[1][2]. Nothing was broken in the way deployments break: the product opened from a direct link, the buy button worked, and the admin panel showed correct inventory ^[3].

The account, published on dev.to, describes a shop selling handmade lighting on a hosted commerce platform with roughly 180 products ^[4]. The author ran the standard pass: 200 OK, crawling allowed, canonical pointing at the preferred URL, product present in the XML sitemap, title and description in the HTML ^[5]. All of it came back reasonable, and by 10:00 there was still no answer ^[6] - about an hour and three quarters of green checks that explained nothing ^[21].

The first real clue arrived as an aside on a call. The administrator had renamed a collection the previous month because the old name, Desk Lamps, sounded too plain ^[7]. The rename also changed the public URL, and the old address began returning 404 ^[8]. Two design articles and an old newsletter had been pointing at that previous URL for more than a year ^[9]. The dashboard did not surface the history attached to the old address, and the release checklist never asked anyone to preserve it ^[10]. The fix was a 301 from `/collections/desk-lamps` to `/collections/workspace-lighting` ^[11], which tells browsers and crawlers the resource moved permanently and keeps the old path working instead of walling it off ^[12].

That repaired one break. The second was the pagination. The new collection rendered its first 24 products immediately, with a Load more button for the rest, and the missing best seller sat in that second group ^[13]. In the initial HTML, the later product links did not exist; they appeared only after JavaScript handled the click ^[14]. Anything past position 24 therefore had no ordinary address for a crawler to follow ^[22]. The repair kept the interaction and put a route underneath it: a real anchor with `href="?page=2"`, which JavaScript can still intercept to update the grid without a full reload ^[15]. As the author puts it, the sitemap was an announcement and the internal links were the road ^[16].

The third problem was volume. The crawl report showed that a catalog of about 180 items had generated more than 2,000 parameter URLs ^[17], roughly eleven addresses per product ^[23]. Nothing malicious: the administrator had switched on filters for room, finish, material, price, availability, and sort order ^[18], producing combinations like `/collections/lighting?room=office&finish=brass&sort=price-asc` ^[20]. Most returned nearly the same inventory in a different order, and some returned empty grids ^[19].

The common thread is that none of the three failures produce a red status anywhere. A rename that orphans a year of inbound links, a button that hides two thirds of a collection from non-executing clients, and a filter matrix that multiplies addresses eleven-fold all render correctly and check out correctly. If your release checklist tests response codes and animation smoothness but never asks what the old URL was, whether the second batch of products has its own address, or how many URLs a new filter can generate, you are shipping the same defect class with a passing report attached ^{[5][10][14][17]}.