Changing site from Aura to LWR, so no more "/s" in the URL and just found out that our marketing team sends out dynamically generated URLs with query string parameters that include not only click trackers but also unique customer identifiers for tracking purposes. That means instead of my accounting for a few hundred unique click tracker variations, it is in the 10s of thousands because native Exp Cloud Site redirection requires explicit URLs.
Such as something like this would all need to be individually stated in the redirect csv.
- https://mysite/s/article?param=1234
- https://mysite/s/article?param=5464
- https://mysite/s/article?param=8798
- https://mysite/s/article?param=4848
I found this thread but that is talking about the explicit redirects, which I will do for base URLs but that won't help with URLs that contain unique query strings.
https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX00000SWIuD0AX
I reached out to our DNS (network) team just to see if maybe we could intercept the call before it gets to Salesforce, but that isn't possible. It also doesn't solve non-Prod testing which are SF URLs for the site, not custom domains.
I have a fallback solution where my LWC on my Site Theme will check on connected callback and redirect, but that isn't perfect because on fast connections the customers still see a flash when they hit the error (404) page before stripping the "/s" out and redirecting them. Worse yet on slow connections you see the error page pretty much render before it hits. Considering adding more of a pause and conditional message on the error page letting them know they will be redirected, but that is still not ideal.
Curious if there are other threads in here I am missing or any other suggestions people have for me to look into / try.
I am still running through validation testing and making sure there aren't some edge cases I am forgetting about but for any URL that contains query string parameters the Head Markup appears to be the best location for this catch-all.
I was trying in an LWC but that causes screen flashes, especially on slow connections. However the Head Markup runs before anything renders and even when throttling my network to emulate a slow 4G, you could see that this solution remove the "/s" and proceed without hitting a 404 page or anything showing. On a fast connection, wouldn't even notice the change.
I am still going to add base page redirects in the native Redirect CSV as that will resolve before even the head markup hits, but this appears to be a solid fallback.
Note: This is a still considered a "fallback" solution. I believe this generates a 404 technically, not a 301. BUT this should be to solve a temporary fix as the long-term resolution is to have our websites, sms, emails, etc updated with the new URL.
