Previous and Next Pagination links and the last link are incorrect when Auto Infinite Scroll SSF and SPRO are enabled

[thinkjarvisdesignandmarketing]

PLEASE COMPLETE ALL STEPS TO SPEED UP BUG FIXES

1. By default the pagination is not updating correctly. This means the prev and next buttons show the very first reload only.
2. So scrolling down to pagination 7 will give you a next and previous of 2 and 3 which would be the very first scroll not the current scroll
3. Also the page 1 of 100 is incorrect. This value only corrects itself if you visit the specific pagination
4. I.e. if you browse to https://www.thehealthworkshop.co.uk/shop/page/17/ You can see the pagination is still updating incorrectly but the total pages changes to the correct value of page 1 of 84. This means the go to last pagination button works just fine but only if you specifically browse to the page.
5. See screenshot - I have removed the display:none tag from the pagination so it is visible.

6. Our SEO audit has picked up on this.
7. The pagination prev and next should update as auto infinite scroll goes down the page
8. Remnove SQL_CALC_ROWS also cannot be used because the max pagination it sets is always a 404 error. So I have disabled this to remove the 404 error from all pages. This does not fix the primary page 1 for each category having incorrect page counts for pagination.

IMPORTANT CONTEXT Screaming Frog audit has picked up on these broken links and then on investigation I saw the pagination prev and next are always wrong.

Proposed solution Correct the logic on Auto Infinite Scroll so it updates the prev and next links correctly with the right page numbers. Correct the shop and category root page counts so they display the correct totals when Remove SQL_CALC_ROWS is set to disabled (Slowest).

Happy to provide a login to the site so you can see the issue yourself.

[thinkjarvisdesignandmarketing]

Settings from auto inf

[thinkjarvisdesignandmarketing]

On further investigation - The issue seems to be something to do with REMOVE_CALC_ROWS. If I disable both, the pagination shows the correct maximum value. If I enable either of these features the max pagination changes to 100. Causing a 404 error on all WooCommerce pages.

The links in the pagination are still incorrect though as the user scrolls although they are hidden using CSS.

Is it possible to get Auto Inf to update the links either side of the current page?

[dhilditch]

@thinkjarvisdesignandmarketing a 404 on ALL woo pages?? That doesn't sound right, there should be a 404 on /page/x if that page does not exist.

re: 7 from your SEO audit, I am not aware of any bots that scroll down the page to then see what page 2 will be, they will use the <link rel="next"...> from the first page and then if you look at that /page/2 you will see the correct pages.

[thinkjarvisdesignandmarketing]

Sorry the 404 I was refering to was /page/100 from the pagination on all pages. The audit could see this 404 link on all pages caused by the remove calc rows setting. I didnt write that very well.

[dhilditch]

Ok and what about number 7? I'm not clear that there is anything to do here - I do not think it's correct to update the meta rel next/prev entries without also updating the browser history and I definitely do not want to do that since then users can end up on page/2 with no way to get to page 1.

[thinkjarvisdesignandmarketing]

Sorry yes - Number 7

As you can see from the screenshot.

The current page is 31 but the rest of the standard pagination doesnt update.

So instead of it being:

FIRST 29, 30, 31, 32, 33 LAST

The current page is the only one that changes - See screenshot.

[dhilditch]

OK but if you load page 31 directly like a bot would, what happens?

I think this is busy work, it will make zero difference to change this, but if you want it to be updated I can do it but I'll have to invoice you.

[thinkjarvisdesignandmarketing]

I see what you are saying. If its not triggering the ajax then it should be fine. It is correct on load but when you scroll it causes the problem - And it is hidden so users cannot interact with it.

What sort of cost would we be looking at out of interest? Im considering it. If you can reply with a cost we can close the issue and I'll message you directly with an instruction if we decide its worth it. Probably ask the client to contribute.

I am waiting for the SEO specialist to complete the audit. Now that I have removed the 404 error caused by the page/100 url I think the audit will come back clean as all of the pagination links are still valid links.

[dhilditch]

It depends. Could be one hour, two hours, three hours or twenty hours.

Twenty hours would be if you are talking about adding /page/2 to the browser history API too because then I would have to implement a scroll-up functionality which I do not want to do.

One to three hours if you're talking about just making the pagination links update, probably only one hour if it's kept super simple.

[thinkjarvisdesignandmarketing]

@dhilditch Just making the pagination links update. So the correct URLs are shown on each auto infinite scroll page load.

Let me know.

The Screaming frog audit came back good. Some pagination related issues but upon investigation they appear to be false positives. Screaming frog is suggestiong that paginated links should be indexed which we know is incorrect. I dont know why it is suggesting this to be honest I dont want pagination in Google as the contents of the page will change continually and we will run out of crawl budget.

[thinkjarvisdesignandmarketing]

@dhilditch Please can you revisit this issue - The pagination needs to update relative to what paginated page you are looking at.

This has now come up in the SEO audits again a problem. If the paginated links either side of the current page do not update then googlebot cannot navigate around the hidden pagination links properly - breaking their ability to crawl the site structure.

Is it possible to get a fix in place so that the paginated links update relative to the current page correctly?