Search-Friendly Navigation
Search-friendly navigation is a set of paths along which a crawler can reach every page you want without losing itself in the ones you do not. Less is documented here than the checklists suggest: a link works only in one form, addresses with "#" are not reliably resolved, and script speed has no threshold of the kind quoted. This lesson covers what is confirmed, where the traps are, and what to do about filters and pagination.
It rests on the JavaScript SEO basics and the faceted navigation guide.
What makes a transition a path
The rule from the documentation: Google can generally crawl a link only if it is an HTML a element with an href attribute. Processing is literal: Googlebot parses the response for URLs in the href attribute of HTML links. A button with a script, an onclick menu, and a card that reacts to a click but contains no link create no paths.
On JavaScript in general the documentation is calm: Google runs JavaScript with an evergreen version of Chromium, so the historic "JS is invisible to the crawler" formula is outdated. But rendering is a separate phase after crawling, and Google Search won't render JavaScript from blocked pages. The chain is covered in the lesson on discovery and crawling.
Addresses with "#" and single-page apps
A separate warning for apps with client-side routing: don't use fragments to load different page content — Googlebot can't reliably resolve such URLs; use the History API instead. A link like href="#/products" is bad practice. The URL structure guide reaches the same conclusion: if you're using JavaScript to change content, use the History API instead.
What a crawler will not follow
| Element | Result | What to do |
|---|---|---|
| An a element with href | There is a path | The foundation of navigation |
| Menus and buttons on onclick without href | No path | Add a real link |
| Routes on "#" | Addresses not reliably resolved | History API and separate addresses |
| Content behind a form entry or a login | A link crawl does not reach it | Move public pages to separate addresses with ordinary links |
The last row follows from crawling working through links; it is not a separate documented rule. The check is simple: what the site crawler finds by links is your navigation as the crawler sees it, and pages with no inbound links are shown by internal link analysis.
Facets: two routes, and they are not equal
Filters turn a catalogue into an enormous number of addresses. Google's recommendation: if faceted URLs need not be indexed, prevent crawling of them; if they do, follow the listed practices. The same guide warns that crawling faceted URLs tends to cost sites large amounts of computing resources due to the sheer number of URLs and the operations needed to render those pages.
The ways to prevent crawling are named in order, and that matters. The first is to disallow them in robots.txt: there is often no good reason to allow crawling of filtered items, only the individual item pages and a listing page without filters. The second is putting filters in a URL fragment. And rel=canonical and rel=nofollow are described for this purpose as generally less effective in the long term: canonical may only, over time, decrease the crawl volume of non-canonical versions.
So the old rule "Disallow or canonical" is imprecise: they are tools of different strength. Plus two details from the same guide: return an HTTP 404 when a filter combination doesn't return results, rather than redirecting to a common "not found" page. And do not combine with noindex: an address blocked in robots.txt will never show Google its tag.
Sessions and parameters
Session identifiers in addresses are a classic trap. The URL structure guide says: wherever possible, avoid the use of session IDs in URLs and consider using cookies instead; you can use robots.txt to block such URLs. The reason is named there too: overly complex URLs with multiple parameters create unnecessarily high numbers of URLs pointing to identical or similar content, so Googlebot may consume much more bandwidth than necessary, or Google Search may be unable to completely index all the content. This is developed in the next lesson on URL structure.
Pagination
The rules for paged lists are written down precisely:
- Link pages sequentially using a href tags to the following page — this helps Googlebot find the subsequent pages.
- Don't use the first page of a sequence as the canonical for all of it — give each page its own canonical URL.
- Don't use "#" fragment identifiers for page numbers: Google ignores them and may not follow the link.
- Google no longer uses the rel=next and rel=prev tags, though other search engines may.
Filter and sort variants on top of pagination follow the same principle as facets: block unwanted URLs from being indexed.
Breadcrumbs: what is documented
A Home → Category → Page trail shows where a page sits. The markup documentation states that a breadcrumb trail indicates the page's position in the site hierarchy and may help users understand and explore a site; a user can go up one level at a time starting from the last breadcrumb. Google uses breadcrumb markup to categorize the information from the page in search results.
One detail usually left out: the feature is available on desktop in all regions and languages where Google Search is available — nothing is promised about mobile results. So the markup is worth adding, but appearing in a snippet is not the reason to. The principles of the structure it reflects are in the lesson on information architecture.
Script speed: what is not in the documentation
The claim that "slow JavaScript is a direct ranking signal and an FCP over 2 seconds hurts positions" is not supported. The page experience guidance lists Core Web Vitals as one of several self-assessment questions, and states: good results in reports don't guarantee a top ranking, and trying to get a perfect score just for SEO reasons may not be the best use of your time. There is no 2-second threshold for FCP in it. Speed should be improved — for people — but not presented as a precise ranking lever.
Diagnosing navigation
- Crawl the site: are all the pages you need found by links.
- Check that menus and pagination use real a href links, not onclick and "#".
- Count the addresses that filters and parameters produce; block them in robots.txt where needed. Their state is in URL auditing.
- Check pagination: each page with its own canonical, no fragments.
- Redirect chains in navigation through the redirect check.
- Conflicts between pages on one topic through cannibalization.
Mistakes
- Menus and pagination on onclick with no href.
- Routes on "#" instead of the History API.
- Treating canonical as equal in strength to blocking facets in robots.txt.
- Putting Disallow and noindex together.
- Redirecting empty filter combinations to a general page instead of a 404.
- The first list page as the canonical for all the rest.
- Session identifiers in addresses.
- Promising ranking gains from load speed as if it were a precise lever.
What comes next
The next lesson is about domains and subdomains: what counts as a separate site and what follows from that.