How infinite scroll works
A script watches how far down the page a visitor has travelled. As they approach the bottom, it requests the next batch of items in the background and appends them to what is already on screen. There is no page reload, and in many implementations the address in the browser bar never changes.
That last detail is what matters for search. A crawler does not scroll. It requests an address, reads what comes back, and follows the links it finds in that response. Items that only exist after several scroll events were never in the response, so as far as the crawler is concerned they are not on the site at all.
Why infinite scroll matters
On a listing of any size, most of your inventory sits below the point where the first batch ends. If nothing else links to those items, the pattern quietly removes them from search — not with an error, just with silence. No alert is raised, and the pages look perfectly healthy to whoever built them.
It has a cost for visitors too. There is no way to bookmark a position, the back button often returns people to the top of the list, and a footer that keeps retreating means anyone hunting for contact details or delivery terms never reaches them. On a phone over a mobile connection — the normal case for most audiences in Nepal — every extra batch is another download the visitor is paying for.
Where infinite scroll goes wrong
The version that causes real damage is the one built as a replacement for pagination rather than a layer on top of it. Take away the numbered addresses and you remove the route a crawler uses to reach deep items, and you also remove the link a customer would have sent to a colleague.
Two smaller problems follow. Updating the address bar with a script while serving nothing useful at those addresses gives you links that break the moment somebody opens one fresh. And appending content while images are still loading pushes the page around under the reader’s thumb, which is precisely the layout instability that Core Web Vitals measure.
What to do about it
Keep a set of real paginated addresses underneath the scrolling behaviour. Each of those pages should return its own items independently, with ordinary links between them, so a crawler walking the series sees everything a scrolling visitor would. The script then becomes a convenience for people rather than the only way in, which is how the pattern was meant to be used.
Test it the way a crawler sees it, not the way it looks in your browser. Fetch the listing and check whether item links are present in the response or only appear once the script has run; this is the same question JavaScript SEO deals with elsewhere on a site. A load-more button is often the better compromise: it gives the visitor a deliberate action and a natural stopping point, it lets the footer stay reachable, and if that button is a genuine link to a paginated address, crawlers follow it as well.