For SEO, give each distinct public page a URL that works when opened directly. Use a fragment to point to a section within a page, not as the only address for a separate product, service, or guide. In a JavaScript app, the fact that a view opens after clicking around doesn't establish that its public route works independently.
This distinction matters when your best answer lives behind an address such as /#/compatibility. A person already using the app may reach it easily, while the team has never checked a fresh arrival. Start by separating page identity from interface state before changing the routing system.
The method below is a proposed review with hypothetical examples. It does not claim that any site was tested or that repairing a route guarantees a ranking, citation, or recommendation.
Distinguish an anchor from a separate view
An ordinary section anchor helps someone reach a part of an existing document. A guide might use #requirements to jump to its requirements heading. The heading and answer belong to the same guide whether or not the fragment is present.
Hash routing uses the fragment to choose application content. MDN describes hash routing as a client-side navigation technique for single-page applications. Its address can look like an anchor while doing a different job.
The practical test is what changes. If the fragment merely moves the reader to an existing section, it is serving navigation within a page. If it replaces a product, guide, or service with a different one, it may be representing a separate public destination. Record that distinction instead of declaring every hash character an SEO defect.
Some fragment state belongs inside a private application: an open drawer, a temporary selection, or a saved workspace view. Making all of that indexable would not automatically help buyers discover useful information.
Check the documented Google requirement
Google's JavaScript SEO guidance recommends the History API for client-side routing between views and says not to use fragments to load different page content. It also calls for links that Google can extract from HTML anchors with href attributes.
That is specific guidance for Google Search. Don't turn it into an assertion that every AI crawler renders pages the same way, or that the History API itself earns citations. The immediate goal is a clear, independently reachable public page.
Changing an address in the browser is only part of that goal. A route also needs to lead to the correct answer on a fresh load. The visible URL can look tidy while the server, app shell, or data loading still sends a new visitor to the wrong place.
Inventory the public destinations before editing routes
Choose a representative section of the site rather than collecting every transient URL. Write down each intended public destination, its current address, its page title, and the answer it provides. Include links from navigation, contextual references, and any shared help instructions.
For each destination, ask whether it represents a distinct reader task. A general guide and its installation heading may belong together. A product overview and a detailed compatibility reference may deserve separate pages when each has a useful independent purpose.
Keep private account views outside this public inventory unless the task explicitly concerns their discoverability. A documentation problem is not authorization to expose application data. Public routes should serve approved public material.
The inventory should also flag aliases. Two addresses for one answer call for a preference decision, while one address standing in for several unrelated answers calls for an identity decision. Those are different issues even if both appear in a routing review.
Use a hypothetical three-part review
Imagine a fictional scheduling service with three links. Its public setup guide uses /help/setup#calendar to reach the calendar section. Its public compatibility page uses /#/compatibility to load a different view. Its signed-in app uses a fragment to remember an open filter panel.
Keep the setup anchor if the section is useful and the complete guide remains available. Plan a real public route for compatibility because a buyer should be able to share and open that answer directly. Leave the private filter state as an application concern unless a separate requirement says otherwise.
Now add an important variation: the compatibility view contains only two sentences already present in the setup guide. A new page may not be the best answer. The team might instead link to a complete compatibility section within the existing guide. A routing repair should follow the content decision, not create a thin page merely to remove a hash.
This review separates three choices that often get bundled into one large migration. It protects useful anchors, gives a real answer a proper destination, and avoids treating private state as public content.
Test a direct arrival, then test navigation
For each planned public route, open the full address in a fresh browser context. Check the final URL, response status, visible title, and exact answer. Record whether it works before visiting the homepage or another app view.
Then follow a normal internal link to the same route. Compare the resulting title and answer. Refresh the page, use Back and Forward, and reopen the copied link in a new context. These are acceptance checks for the proposed change, not claims about how a crawler executes browser history.
A route that works only after an internal click is unfinished for a first-time reader. A route that refreshes into a generic homepage has also failed the intended destination check. Name the specific failure so the developer can investigate the correct server or application layer.
Use a known missing route as a comparison. The purpose is to check that the application distinguishes a valid public answer from an address that doesn't exist. Don't accept the presence of a generic app shell as proof that every route is healthy.
Inspect the answer, not just the status code
A successful response can still show the wrong product, an empty loading panel, or a previous route's title. Search for an exact sentence that should be unique to the destination and compare it with the approved content source.
Inspect the rendered page after its normal load. Record content absence separately from slow loading and incorrect data. If the expected material appears only after an unrelated action, describe that dependency in the issue rather than assuming a new URL solved it.
After deployment, inspect the public URL through Google's available URL Inspection workflow as well. Compare that evidence with your browser observation. An expected sentence appearing in an inspected render is a narrower conclusion than the page being indexed or selected for a search.
Keep dates and conditions with each capture. An old indexed observation and a current live test answer different questions. Neither should silently replace the other in a launch review.
Preserve existing entry paths deliberately
Before changing public addresses, list the old entry paths that readers may still use. Decide how the site will handle those arrivals and make the behavior part of the release plan. Fragment-based routes require care because the old view may be selected in the client rather than arriving as a distinct server path.
Test the old full address in a fresh context after the change. Confirm it leads to the intended answer or gives a clear, appropriate next step. Don't mark the migration complete because the new navigation menu looks correct.
Update the links you control to use the chosen public destinations. Check descriptive anchor wording, breadcrumbs where present, and references in related documentation. A clear route is easier to maintain when the site's own links agree about it.
Write a completion note the next engineer can trust
Record which items were section anchors, public views, and private state. For changed public views, include the intended answer, old and new addresses, direct-load result, internal-navigation result, and deployed inspection date. State unresolved differences plainly.
Keep the outcome modest and useful: a buyer can open and share the intended public answer without depending on a previous app session. Search discovery and AI visibility can build on that foundation, but they still depend on content relevance, evidence, and each engine's selection process.
Start with one meaningful public answer. Make its identity clear, verify a fresh arrival, and preserve the useful paths people already have.
Hey I'm Uriel Bitton. I write about SEO, AEO, GEO, and helping brands get found in AI answers.
Subscribe for practical ways to grow your brand's visibility in search and AI answers.
Explore HoneyWeRank for SEO and AI visibility.
Top comments (0)