I thought that as my original thread might pass some people by, I should post the outcome to a new one that might be more obvious. Guessing savvy users will have worked this out for themselves already so please be patient as I share this for the benefit of others like myself who were caught off guard!
There is a potential SEO issue for vertical scrolling projects
This impacts the way you should and shouldn’t use them. Support have confirmed this as a feature not a bug (though I’ve asked if some accommodation could be made to give us options).
What’s the issue?
It relates to canonicals. For anyone that doesn’t know, the canonical link is part of the header information like the page titles and descriptions. It’s a way to indicate to search engines if the current page is the primary source of content or a duplicate/variation on another existing page.
If you have a bunch of very similar pages, the chances are that Google will look at these and say ‘hey they’re all the same, I’m binning all but the one I think is most important’. To control that process, you set the preferred page to have it’s own address as canonical and then all the others then also point to the preffered one. Job done.
On Readymag, the configuration used is that if you have a horizontal project where you navigate side to side, all the pages will be self-canonical. Not sure if this goes for sub pages but I would imagine not.
If you have a vertical scrolling project, only the first page in the project will be self-canonical. All pages below will point back to the very first page so Google etc will always see the entire project as a single page.
So why’s that an issue?
If you use the magazine-like model of having a ‘cover’ page and subsequent content pages accessed on a vertical scroll, none of your actual content will be indexed by default as Google will look at it and go “Oh they’re all just copies of this page. What’s on it? Just a headline and a photo? That’s not very interesting, in the bin it goes!”
Even if your publication is only a single feature, you’ll still face the same issue if you have put actual content onto subsequent pages on a vertical stacked pages.
To show this, I did an experiment on powers.worldwhiskyday.com. An old project that’s been sitting up there for years. When I looked in Google Search Console, I could see that none of the pages were indexed and that the reason given was that another page with correct canonical existed (ie the cover).
I then added this to the project using the code editor. It includes a listener to update when the URL changes but that part doesn’t seem to work as a view the page source. However on load, it does overwrite the canonical tag with the current URL which is what we need and that appears to be enough for GoogleBot.
<script type="text/javascript">
// Function to update canonical URL
function updateCanonicalUrl() {
const currentUrl = window.location.href;
const canonicalTag = document.querySelector("link[rel='canonical']");
if (canonicalTag) {
canonicalTag.href = currentUrl;
}
}
// Listen for URL changes
window.addEventListener("hashchange", updateCanonicalUrl);
// Initial call to set the canonical URL
updateCanonicalUrl();
</script>
After a couple of days, I can see that all the subpages of this project are now indexed and that the canonical issue has gone from Google Search Console and quote searching for the H1s does bring up the pages.
I thought this was important to share as it’s really just presented as an aesthetic choice without mentioning that it has massive impact on search visibility. I’m sure there will be cases out there where pages are indexed in spite of this - Google is big and weird that way - so I’d be interested to hear other people’s experiences.
Ideally I’d like to see the canonical added to the meta options in the page settings with options for ‘self’, ‘initial’, ‘parent’ or ‘other’.
Also, if anyone finds a way to make the event listener work properly so as to update live, that’d be cool (although clearly it’s not a biggie).