A while ago I was struggling with permanent redirects problem. The page linked as a shortcut was not updated; always first version was used as a redirect destination. I had no idea where it could be cached. Of course at the end it turned out that the explanation of this situation is very obvious.
The scenario to reproduce the problem
I had three pages. Two standard articles (“Page 1” and “Page 2”) and “Link page” page with shortcut to one of article.
I created “Link page” and set “Page 1” as shortcut (using standard Manage Shortcut functionality). Everything works fine. Then I updated shortcut link to “Page 2” as a redirect destination.
After I click “View on website” button I was still redirected to “Page 1”. I verified the network traffic in the browser developer tools. There was a request to “link‑page” with status 301, and then unexpected request to “page-1”.
I thought that it’s a server caching, so I tried to find some output cache settings, but with no luck. After a long while of searching I started the Fiddler to check the communication between client and server. After I refreshed “Link page” the only request captured in Fiddler was the one to “Page 1”.
Everything was cached by the browser. Browsers strongly cache 301 redirects so there was no bug. After I added a querystring parameter to “Link page”, the “Page 2” was displayed. The Fiddler also showed request to “Link page”.
Same with the browser network traffic, it shows “page-2” as I wanted.
EPiServer 10.3 update
In EPiServer 10.3 update (Page shortcut incorrect after updating Name_of_URL of destination page), the “View on website” link has an additional dynamically generated querystring parameter. That makes those links unique, so they will never be restored from browser cache. It means, that when previewing shortcuts from edit mode, always the proper page is displayed.
But still, if someone in view mode displayed a page version, the redirect will be cached by the browser for a very long time.
