DEV Community: Vladyslav Yanchenko · Salestudia

Debugging 404 URLs That Weren't Links: A React Breadcrumb Case

Vladyslav Yanchenko · Salestudia — Sun, 15 Nov 2026 14:05:25 +0000

Disclosure: This article was generated with AI from a documented site audit. The code and paths below are simplified examples, not private repository excerpts.

A path in a 404 report can look close enough to a real route that your first instinct is to redirect it. On HandMen’s German-language guide site, the reported paths looked like existing pages with -1 or -2 tacked onto the end. The useful clue was not a missing route or a breadcrumb link. It was a URL-shaped string emitted as a React list key.

The distinction mattered: the team could remove the string at its source without redirecting a page that had never been shown to exist.

Look for a route, a link, and a string separately

Take one reported URL and one plausible source page. If the report shows a referring page, treat it as a starting point, not a complete record of how the URL was discovered.

Request the two paths. Is the intended route live, and does the suspicious variant actually return 404? Check the response status as well as what the page looks like.
Check navigation targets. On the candidate source page, inspect actual anchor destinations in the response and in the rendered DOM. Google’s crawlable-link guide explains why an anchor with an href is the relevant comparison. A substring search alone cannot establish that a matching link exists.
Search for the full variant in the response. Note where the match occurs: an anchor, canonical, hreflang, structured data, or a serialized payload. Check the sitemap separately. A string in a payload and a visible navigation link are different findings.

In the HandMen audit, 186 of the reported variants matched breadcrumb keys in serialized output. None of those matches was a corresponding breadcrumb href. A separate reported path came from template data and needed a different diagnosis. This establishes where the strings appeared in the output that was examined. It does not prove what Google used to discover them.

Keep the key separate from the destination

Here is a simplified version of the pattern. Suppose item.href is /guides/flooring and the item is at position 2:

// The destination is /guides/flooring.
// The key can become /guides/flooring-2.
items.map((item, index) => (
  <li key={`${item.href}-${index}`}>
    <a href={item.href}>{item.label}</a>
  </li>
));

A key is React bookkeeping, not an anchor attribute. In this case the page’s rendering pipeline exposed the key in serialized output. Don’t assume every React application serializes keys the same way: inspect what your build actually serves.

At this site, breadcrumb paths were already stable and unique among siblings, so the fix removed the positional suffix:

items.map((item) => (
  <li key={item.href}>
    <a href={item.href}>{item.label}</a>
  </li>
));

If a breadcrumb can repeat the same destination, use an explicit, stable identifier from the data instead. React’s list rendering documentation explains the sibling-uniqueness and stability requirements.

Verify the fix in the response, not just in the component

For a regression check, compare the same suspect strings with the rendered link destinations before and after deployment. In the November 10 production check, the team sampled 12 pages across guide listings, articles, and illustrative project pages. The sampled real routes still responded with HTTP 200, the suffix strings were absent from those pages, canonical targets remained correct, and intentional noindex directives on the example pages stayed in place.

That is a deployment check, not a Search Console outcome. We did not establish when the report would clear or whether any ranking changed. If a flagged URL has no real page or useful replacement, don’t create a redirect merely to make the report shorter. Fix the generator first; add a redirect only when you have evidence of an actual URL move or a relevant replacement.

A Technical SEO Checklist Before Launching a Small Business Website

Vladyslav Yanchenko · Salestudia — Thu, 12 Nov 2026 10:09:05 +0000

A small business website can look finished while its important pages still carry a staging noindex rule, point to the wrong canonical URL, or disappear from the mobile navigation.

This checklist covers a practical release review for a service business website. Run it against the production domain before announcing the launch, then repeat the public checks after deployment. For an online store, include a category and product page in the sample.

1. Decide which pages should appear in search

Start with a short URL inventory: the homepage, service overview, one service detail page, an article, and the contact page.

For each public page intended for search, check:

The final response is 200 OK and contains the expected content.
Neither the HTML nor the X-Robots-Tag response header contains an unintended noindex.
robots.txt allows the crawling needed to inspect that page.

Keep deliberate exclusions where they belong. Private staging environments should have access controls. Also, blocking crawling does not reliably remove an already known URL from search: Google must be able to fetch a page to process its noindex rule.

Reference: Google's noindex documentation.

2. Inspect redirects on real page paths

Test HTTP and HTTPS, plus www and non-www versions, using a service page as well as the homepage. A redirect should preserve the intended destination.

Replace this example URL with your own:

curl -sS -L -D - -o /dev/null 'http://example.com/services/'

This prints the response headers along the redirect chain while discarding the body. Check each status and Location header, then the final response.

Use 301 or 308 for permanent moves. Use temporary redirects for genuinely temporary changes. Avoid loops, unnecessary hops, and a rule that sends every old page to the homepage.

Reference: Google's redirect guidance.

3. Check the canonical on each page type

A unique page can declare its own preferred URL:

<link rel="canonical" href="https://example.com/services/" />

Look for staging domains, incorrect hosts, or templates that give every service page the same canonical.

Canonical signals are intended for duplicate or very similar pages. A separate service page with distinct content should not automatically point to the homepage. Google can select a different canonical, so also check its indexed decision later.

Reference: Canonical URL guidance.

4. Connect navigation and sitemap entries

Reach each important page through ordinary navigation or a relevant contextual link. Use crawlable HTML links with real destinations:

<a href="/services/">Explore our services</a>

In the XML sitemap, list the preferred public URLs you want indexed. Remove staging addresses, redirects and intentionally excluded pages. Check that listed URLs work.

A sitemap helps discovery; it does not guarantee indexing or replace useful navigation.

References: Crawlable links and building a sitemap.

5. Review titles and descriptions in context

Give important pages distinct, descriptive titles and clear visible headings. Write descriptions that accurately summarise their contents.

Avoid repeating the same generic title across every service page. Google can generate different title links and snippets, so these fields are inputs rather than a guaranteed search-result preview.

References: Title links and search snippets.

6. Test the mobile experience and performance

On a phone, open the menu, follow a service link, read the main content, and complete a test enquiry. Check whether banners obscure controls or elements shift while loading.

Use PageSpeed Insights to investigate performance. Current good Core Web Vitals thresholds are:

Metric	Good threshold
Largest Contentful Paint (LCP)	2.5 seconds or less
Interaction to Next Paint (INP)	200 milliseconds or less
Cumulative Layout Shift (CLS)	0.1 or less

These thresholds apply at the 75th percentile of real visits, with mobile and desktop considered separately. A new site may lack sufficient field data. Lab testing helps find issues; a Lighthouse score alone does not establish real-world performance.

References: Core Web Vitals and Google Search guidance.

7. Verify the public deployment in Search Console

After launch, inspect representative URLs using Search Console's live test. Review what Google can fetch and render.

Then distinguish the live test from the indexed report: the former checks the current page, while the latter reflects Google's indexed information. The live test does not predict Google's canonical selection. Requesting indexing also does not guarantee inclusion.

Reference: URL Inspection documentation.

Record a clear result for each check

A small release log makes fixes easier to verify:

Check	Evidence to record
Public access	Final status, visible content and robots directives
Redirects	Tested starting URL, each hop and final destination
Canonical	Declared URL and whether it matches the page
Discovery	Internal link and sitemap entry
Mobile usability	Device, task tested and any obstruction
Search Console	Test date and live versus indexed result

Fix launch blockers first: accidental exclusions, broken destinations, incorrect canonical templates and unusable mobile navigation. Keep remaining improvements in a dated follow-up list.

About the author: Vladyslav Yanchenko works on SEO and website structure at Salestudia in Germany. The agency's SEO audit and optimisation overview explains the broader scope of that work.