History issue - extra parameter

[Nuranto]

ias.on('page', (event) => {
            // update the title
            document.title = event.title;

            // update the url
            let state = history.state;
            history.replaceState(state, event.title, event.url);
        });

Strange behaviour :
1/ I scroll, ?p=2 is added => OK
2/ I scroll again ?p=2 is replaced by ?p=3&1581932043014= instead of ?p=3 => not OK

I don't like it because I don't want google to see that and index such URL. I don't know if it could, but I know that google is better and better using JS...

[fieg]

Interesting. I don't see this happening in my example. Do you happen to have a live url which I can inspect?

Also, on a side note:

I don't like it because I don't want google to see that and index such URL. I don't know if it could, but I know that google is better and better using JS...

Yes, Goolge can index JS these days. To avoid indexing issues with duplicate content you should add a canonical meta tag to you page.

[Nuranto]

Interesting. I don't see this happening in my example. Do you happen to have a live url which I can inspect?

Neither do I. Maybe because you don't manage pages with GET parameters in your example. I will send you the URL to inspect in PM.

Also, on a side note:

I don't like it because I don't want google to see that and index such URL. I don't know if it could, but I know that google is better and better using JS...

Yes, Goolge can index JS these days. To avoid indexing issues with duplicate content you should add a canonical meta tag to you page.

We do have a canonical, however I've been told that it does not work in all cases... So I try to not rely on it when I can.

[fieg]

Thank you for sending your url. I had a look at it and saw that your server appends any url parameter to your pagination links. SEO-wise I would advise against this (or set a canonical meta tag), but other then that it shouldn't be a problem.

The number you see in the urls is added by IAS as a cache-busting solution (see here). This is not something I'm a fan of and already have this on my todo list. I'll try to move it up a bit on the priority.

[Nuranto]

Ok, I understand. I'll see on my side if I can change the server behavior.
However, I wonder why you want/need to bypass local cache ?

[fieg]

However, I wonder why you want/need to bypass local cache ?

I agree that this needs an overhaul.

[fabiocaccamo]

@fieg why you closed this issue? I'm using 3.0.0-beta.6 version and this issue has not been fixed?
Is there any new parameter to avoid this issue?

[fieg]

This has been fixed in master, but I haven't released it yet. You could help me out by testing the fix using the latest from master and letting me know if it works for you. https://github.com/webcreate/infinite-ajax-scroll/blob/master/CONTRIBUTING.md#generating-dist-files-from-source

[fabiocaccamo]

@fieg sorry, for me the problem was on server side, because the url renderer merge existing query-string parameters with new parameters, but since the timestamp is passed as key instead of as value, it was never replaced, so a new parameter was added at every request.

[fieg]

Fixing it on the server side is also an option, but the latest version in master allows you to disable the timestamp in the url. See https://github.com/webcreate/infinite-ajax-scroll/blob/master/docs/events.md (load event) for an example.