Question for the SEO people. On a tube category page, is it better to paginate, real page 1, 2, 3 links, or infinite scroll that loads more as you scroll? My worry is crawl budget. With infinite scroll the bot don’t scroll, so it see only the first batch and the rest of the videos never get a crawl path. I am testing paginated with clean ?page= links and a self-reference, but i want to hear what actually work for people, not theory. And does the answer change if a category has 5000 videos versus 200?
googlebot doesnt scroll, so pure js infinite scroll hides everything past the first load unless theres also a crawlable path. what works is infinite scroll for users if you want it, backed by real paginated urls (?page=2 and so on) that exist and link to each other so theres a path to every video. 200 videos or 5000 just changes how bad it hurts, not the fix. on a big category a bare load-more with no pagination leaves most of your long tail uncrawled, and the long tail is where tube seo usually lives.
agree with dave, and i log this. on one site i switched a category from load-more to real ?page pagination and the video pages google crawl per day went up a lot inside two weeks, i have the screenshot in my sheet. one warning, dont noindex page 2 onward, and dont lean on rel next/prev to save you, google dropped that signal years ago. just make the deeper pages crawlable, indexable and linked.
the setup that holds up is progressive enhancement. server render real anchor links to /category/x?page=2, then let js hijack them for infinite scroll on the client. the bot follows the anchors, the user gets the scroll. if your script only paints the grid after an xhr fires, thats the version that tanks the crawl. check the raw html with curl, not what devtools shows you.
yeah. view source, not devtools. if the video links arent in the initial html the bot doesnt see them, end of story. half the “infinite scroll killed my seo” posts are just client rendered grids with an empty source.
paginate. every time someone gets clever with infinite scroll on a content site they’re back in six months asking why the long tail deindexed. lol. boring paginated links that work beat a slick scroll that doesn’t, every single time.
right default for a content site, and i’ll back it from client work. the clever infinite-scroll builds look great in a demo and then quietly hide half the catalog from the crawler, because if the deeper content only loads on scroll with no real url, google often never reaches it. real paginated urls the bot can request keep your deep pages discoverable, which on a big tube is most of your pages. layer a nice scroll on top for users, but the crawlable pagination underneath is non-negotiable.
the pattern that satisfies both is infinite scroll for humans backed by real paginated urls underneath. build proper page-2, page-3 urls that work with javascript off and return the actual content, then enhance with scroll-to-load for js users. crawler and no-js visitors get clean pages, everyone else gets the smooth scroll. the failure is scroll with no real urls behind it, content that only exists after a js fetch google may never trigger.
the honest tube take is you can have the infinite-scroll UX and the SEO, but only if the crawlable pages exist underneath, and most people who go clever skip that part. i have watched sites bolt on pure javascript infinite scroll and lose the long tail because the deep videos had no addressable URL for the bot to find. if the scroll is decoration over real paginated pages, fine. if the scroll IS the navigation and there are no underlying pages, you just hid your catalog from google. the shortcut that feels modern is the one that quietly buries your deep content. real URLs or the crawler cannot see past page one.
you can have both only if the crawlable pages exist underneath, and most people who go clever skip that part. infinite scroll over real paginated urls is fine, infinite scroll that IS the navigation with no underlying pages hides your catalog from google. build the real page-2, page-3 urls that work with javascript off, then enhance with scroll for users. pretty for humans, real urls for the bot, or the crawler never gets past page one.
progressive enhancement, real paginated urls underneath and scroll-to-load on top for users with javascript. build the proper pages that return actual content with js off, then decorate with the smooth scroll, so the crawler and a no-js visitor both get clean paginated pages and everyone else gets the nice experience. the failure is scroll with no real urls behind it, content that exists only after a fetch google may never trigger. real pages first, scroll second.
paginate, every time, is the right default for a content site, because the clever infinite-scroll builds look great in a demo and then quietly hide half the catalog from the crawler. if the deeper content only load on scroll with no real URL, google often never reach it, and on a big tube that deep content is most of your pages. layer a nice scroll on top for users, the crawlable pagination underneath is non-negotiable.
its a false choice, you build both. paginated real urls underneath, infinite scroll bolted on top as a nicety. the crawler and anyone with js off walks numbered pages, a normal user gets the seamless scroll over the exact same pages. people pick one or the other like they have to, and you dont.
worth spelling out on the wordpress side, because the scroll has to be built as loading the next real paginated page and updating the address bar, not a separate client-only feed. if a plugin builds it as its own feed with no crawlable paginated version underneath, that is the uncrawlable version everyone warns about. the paginated pages stay the source of truth and the scroll just rides on top of them.
paginate, every time, is the right default for a content site, because paginated real URLs are crawlable, bookmarkable, and where a lot of your long-tail category-plus-page-two traffic lives, so the safe foundation is always real pagination whether or not you add scroll on top. so pagination is the non-negotiable foundation. so make real pagination the base and treat infinite scroll as an optional enhancement over it, because the paginated URLs are the durable crawlable structure that carries real traffic and the scroll is just a UX layer, so the operators who replace pagination with a pure infinite-scroll feed lose the crawlable URLs and the long-tail traffic they carry, while the ones who keep pagination as the foundation and add scroll on top keep both, which means the default should always be real pagination, with scroll as the enhancement rather than the replacement, since the paginated pages are where the SEO value lives and giving them up for a slicker scroll that indexes nothing is exactly the tradeoff the satisfies-both pattern exists to avoid, so paginate first and decorate with scroll second.
this is the point that dissolves the whole pagination-versus-infinite-scroll argument. you do not pick one. you build real paginated crawlable urls underneath and lay the infinite scroll on top as an enhancement. users get the smooth scrolling they like, crawlers and anyone with js off get discrete indexable pages. the smooth experience and the crawlable structure are not in tension, they just live at different layers, so the either-or framing is a false choice.
defensible default for a content site. pagination give you clean crawlable indexable pages out of the box, and infinite scroll can hide content from the crawler if it is done carelessly. so for a site whose traffic depend on search, paginate by default and add the scroll enhancement only carefully on top, as a proper hybrid over real pages. it is the safe choice because it guarantee the crawlable structure first, and the smooth-scroll nicety never come at the cost of the content staying indexable.
from the build side, the pagination-versus-infinite-scroll question is really about implementation quality, because a well-built hybrid gives you both the smooth UX and the crawlable pages while a careless infinite scroll hides content and a clunky pagination annoys users, so the outcome depends on how well it is built. so the outcome depends on build quality, a good hybrid gives you both. so invest in building the pagination-and-infinite-scroll solution well, because a quality hybrid delivers both the smooth experience and the crawlable pages while a careless implementation of either fails, so the operators who get this right treat it as an implementation-quality problem rather than a fundamental choice, which means the pagination-versus-infinite-scroll outcome is decided by how carefully the solution is built, since a good hybrid captures both benefits and a sloppy version of either approach loses one, and the build-side lesson is that the right answer, infinite-scroll UX over crawlable paginated URLs, only delivers if implemented properly, making the investment in a quality build the thing that actually determines whether you get both the user experience and the SEO rather than sacrificing one, because the technically sound hybrid is entirely achievable and the failures come from careless implementation rather than from any real need to choose between the two.
you do not actually have to choose here. put the infinite-scroll experience on top of real paginated, crawlable URLs and you get both, the smooth scroll for users and discrete indexable pages for the crawlers. the whole pagination-versus-infinite-scroll fight kind of goes away once you build it as a hybrid.
on the build side i would default to pagination every time for a content site that lives on search. it gives you clean crawlable pages for free, where infinite scroll can quietly hide content from the crawler if you are not careful. layer the smooth scrolling on top of the paginated foundation, but do not let it replace it.