eg does 1427 match the id of the content item in Umbraco?
If you preview a page in the backoffice, notice the Url at the top, and that it includes the id of the page, now if you 'close' preview (not the browser) in some versions, Umbraco redirects you to a URL which includes the ID, and you are no longer 'in preview'.
I wonder if that could account for what you are seeing?
Yes, it does correlate to the preview ID for the pages.
The visits aren't just internal/from Umbraco editors as the pageviews are too high and GA is showing a mix of sources. It's like a duplicate .aspx URL is being created when the pages are published.
But as Bo points out there maybe a plugin, DocTypeGridEditor? that utilises this 'preview', certainly in the backoffice, and so turning this off might affect that!
The reason .aspx 'is a thing' - is that back in the day, a .net web application would have all it's pages with a .aspx file extension, so the webserver new it was a .net app - but as the world has evolved and nice URLs without extensions have become preferred, it's been made to work without the .aspx extension... but it's still there buried within the .net framework, and it's there in Umbraco, I think for legacy reasons too or just not updated in preview...
You probably also have a server rewrite rule that's enforcing there to be a / on the end of your URLs, that isn't clever enough to ignore extensions! which is why it's becoming .aspx/
We've set disableFindContentByIdPath="true" so these pages now 404. Will keep an eye on a 404 report to check users aren't trying to access these URLs.
.aspx pages showing in Google Analytics
Hello all,
When I publish new pages on a client's website, a duplicate /1234.aspx/ URL appears in Google Analytics.
e.g.
/1427.aspx/ is shown as well as the true URL: https://nightingaledesignresearch.com/insights/research-methods-user-journeys/
All the traffic to the .aspx URL is from Chrome, but there is also Chrome traffic visiting the true URL.
Does anyone know what the issue could be?
TIA, Lucy
Hi Lucy
Is this preview related?
eg does 1427 match the id of the content item in Umbraco?
If you preview a page in the backoffice, notice the Url at the top, and that it includes the id of the page, now if you 'close' preview (not the browser) in some versions, Umbraco redirects you to a URL which includes the ID, and you are no longer 'in preview'.
I wonder if that could account for what you are seeing?
regards
Marc
Hi Marc
Thanks for replying :-)
Yes, it does correlate to the preview ID for the pages.
The visits aren't just internal/from Umbraco editors as the pageviews are too high and GA is showing a mix of sources. It's like a duplicate .aspx URL is being created when the pages are published.
Any idea how I could prevent that from happening?
Thanks, Lucy
Hi Lucy.
Do you by any chance use any plugins that also might call the preview function?
Hi Lucy
If you look in your /config/umbracosettings.config file and find the web.routing element:
You'll see a number of settings that can effect the routing of requests.
If you set
disableFindContentByIdPath="true"
then the requests for
https://nightingaledesignresearch.com/1427/
https://nightingaledesignresearch.com/1427.aspx/
should no longer 'find content by Id'
But as Bo points out there maybe a plugin, DocTypeGridEditor? that utilises this 'preview', certainly in the backoffice, and so turning this off might affect that!
The reason .aspx 'is a thing' - is that back in the day, a .net web application would have all it's pages with a .aspx file extension, so the webserver new it was a .net app - but as the world has evolved and nice URLs without extensions have become preferred, it's been made to work without the .aspx extension... but it's still there buried within the .net framework, and it's there in Umbraco, I think for legacy reasons too or just not updated in preview...
You probably also have a server rewrite rule that's enforcing there to be a / on the end of your URLs, that isn't clever enough to ignore extensions! which is why it's becoming .aspx/
regards
Marc
Yes, we are using DocTypeGridEditor
We've set disableFindContentByIdPath="true" so these pages now 404. Will keep an eye on a 404 report to check users aren't trying to access these URLs.
Thanks both for your help 🙏🏻
is working on a reply...