Select to view content in your preferred language

Stop using Hash (#) URLs in ArcGIS Sites / Enterprise Apps and allow Native Vanity URLs for SEO

245
0
3 weeks ago
Status: Open
PhilipPhilipsen
Emerging Contributor

Currently, ArcGIS Enterprise Sites and several other apps use a Single Page Application (SPA) architecture that relies heavily on fragment identifiers / hashes (#) in the URL structure (e.g., .../portal/apps/sites/#/pages/page-name).

While this works fine for internal app navigation, it creates a massive roadblock for public-facing portals. Major search engines completely ignore everything after the # character on a server level. This makes it technically impossible for search engines to index individual subpages of an ArcGIS Site, severely hurting SEO and discoverability.

Why this is important: Public organizations, utilities, and local governments need their public data, maps, and guides to be easily discoverable via search engines. If a citizen or professional user searches for a specific public map or analysis, search engines should lead them directly to that subpage, not just to the generic portal homepage.

My Proposal:

  1. Ditch the Hash (#) URLs: Transition ArcGIS Enterprise Sites (and modern web apps) away from hash-based routing to standard web routing, ensuring every public page has a unique, clean URL that search engines can crawl and index natively.

  2. Native Vanity URLs / URL Shortener: Introduce a built-in feature in the Enterprise Portal/Sites manager where administrators can easily generate short, user-friendly aliases (e.g., [www.domain.com/maps](https://www.domain.com/maps) or [www.domain.com/guide](https://www.domain.com/guide)) that natively redirect to the correct app or site page.