TL;DR
Infinite scroll breaks SEO at a fundamental level because Googlebot doesn’t scroll. It loads your page, sees only above-the-fold content, and leaves. Every product below that initial viewport doesn’t exist to Google. The “fix” most developers implement (adding a /page/2 parameter) creates a different problem: duplicate content and crawl waste. Real solutions require understanding that infinite scroll and SEO serve opposite masters. Users want seamless browsing. Google needs discrete, crawlable URLs. You can’t fully satisfy both, so you need to choose a primary mode and gracefully degrade the other. What nobody mentions: infinite scroll also tanks your Core Web Vitals through Cumulative Layout Shift as new content pushes existing content around, and destroys browser back-button functionality through bfcache incompatibility.
The Conversation
Priya, product manager at a DTC furniture brand, 28 employees, $6.8M revenue, Shopify Plus with custom theme, basic SEO knowledge from reading blogs, previously assumed “Shopify handles SEO,” moderate urgency after noticing category page traffic plateau: Our developer built this beautiful infinite scroll for our collection pages. Customers love it. But I just realized our products might not be getting indexed. Someone said Googlebot doesn’t scroll?
SDC SEO Brain: Correct, but the mechanism is more complex than most explanations suggest. Googlebot’s rendering is two-phase and asynchronous. Phase one: Googlebot crawls your HTML immediately and extracts any server-rendered links. Phase two: the page enters Google’s Web Rendering Service (WRS) queue for JavaScript execution. WRS uses headless Chromium to run JavaScript and capture the final DOM. The critical gap: WRS queue wait times range from hours to days, sometimes weeks during high-load periods. Even your initial 8 products aren’t “seen” instantly. They’re seen whenever WRS processes your page. And WRS doesn’t simulate scroll events, so scroll-triggered content never renders. Check this yourself: in Chrome, go to one of your collection pages, right-click, View Page Source. That’s phase one. Now open DevTools, go to Elements tab. That’s what WRS eventually captures, but without any scroll-triggered content.
Priya: So the initial load matters. How many products show before scrolling?
SDC SEO Brain: That’s the key question. Open your collection page, don’t scroll at all, and count visible products. That’s your Googlebot-visible inventory.
Priya: Eight products. We have 340 products in this collection.
SDC SEO Brain: Important clarification: is that 8 products on mobile or desktop? Google uses mobile-first indexing, meaning Google primarily sees your mobile rendering. If your mobile viewport shows 4 products and desktop shows 8, Google sees 4. Check specifically on mobile viewport or use Chrome DevTools mobile emulation when counting.
Priya: Let me check mobile… Only 4 products visible on mobile before scrolling.
SDC SEO Brain: So Google potentially sees 4 out of 340 products on this page. The other 336 might as well not exist from an indexing perspective. They have no crawlable path to discovery unless they’re linked from somewhere else on your site.
Priya: But our products are in our sitemap. Doesn’t that help?
SDC SEO Brain: Sitemap helps Google discover product URLs exist, but doesn’t help the collection page rank for category-level queries. There are two separate problems here. First: are individual products indexed? If they’re in your sitemap and have internal links from somewhere, probably yes. Second: does your collection page rank for queries like “modern sofas” or “sectional couches”? That depends on what Google sees when it crawls the collection page. If Google only sees 4 products, it might not consider your collection page a comprehensive resource for that category.
Priya: We’re on page 2 for “modern sectional sofa” and we have 47 sectionals. Competitors on page 1 have fewer products than us.
SDC SEO Brain: Content depth is only one ranking factor. But let’s isolate whether infinite scroll is hurting you. Use Google’s URL Inspection tool in Search Console. Inspect your sectionals collection page. Look at the rendered HTML. How many product links appear in the rendered version?
Priya: Checking… The rendered HTML shows 4 product links. Same as initial mobile viewport.
SDC SEO Brain: That confirms WRS isn’t triggering your scroll-load. But here’s a nuance: how does your infinite scroll detect when to load more? Traditional scroll event listeners or Intersection Observer API?
Priya: I’d have to ask the developer. Why does it matter?
SDC SEO Brain: Intersection Observer behaves differently than scroll events. It fires when elements enter the viewport. In some implementations, WRS might trigger Intersection Observer callbacks because elements technically “intersect” the viewport during render, even without scrolling. This is inconsistent across implementations. Your test with URL Inspection shows it’s not working in your case, but I’ve seen implementations where Intersection Observer accidentally loaded one extra batch. The point: don’t assume, always test with URL Inspection for your specific implementation.
Priya: Our developer said he added pagination for SEO. There’s a /collections/sectionals?page=2 parameter.
SDC SEO Brain: That’s a common “fix” that often creates new problems. Let me guess: users see infinite scroll, but the paginated URLs exist in the background for crawlers?
Priya: Yes, exactly.
SDC SEO Brain: Check whether those paginated URLs are actually linked anywhere. Look at your collection page source. Is there an actual anchor tag pointing to ?page=2?
Priya: I don’t see any links to page 2 in the source.
SDC SEO Brain: Then Google can’t discover page 2 through crawling. The URLs exist if someone types them directly, but Google doesn’t know they exist. Your sitemap probably doesn’t include paginated URLs either?
Priya: No, just the main collection URL.
SDC SEO Brain: So you have phantom pagination. The URLs technically work but have no crawl path. Meanwhile, your infinite scroll doesn’t expose content to Googlebot. Worst of both worlds.
Priya: Great. How do I fix this?
SDC SEO Brain: First, let’s understand the tradeoffs. You have three options, each with downsides. Option one: hybrid approach where you keep infinite scroll for users but add visible pagination links for Googlebot. The pagination links are in the DOM even if visually hidden or styled as secondary navigation. Option two: switch to pure pagination, abandoning infinite scroll entirely. Option three: improve initial load to show more products above the fold, accepting that products beyond that won’t be crawled from this page.
Priya: Our UX team won’t accept removing infinite scroll. Customers love it.
SDC SEO Brain: Then option one is your path. But before we go there, I need to tell you about a problem with infinite scroll that almost nobody discusses: Core Web Vitals impact, specifically Cumulative Layout Shift.
Priya: What’s that?
SDC SEO Brain: CLS measures how much page content shifts unexpectedly during loading. When infinite scroll loads new products and inserts them into the page, existing content gets pushed down. Users who are about to click a product suddenly find themselves clicking the wrong thing because the page shifted. Google measures this. CLS above 0.1 is “needs improvement,” above 0.25 is “poor.” Infinite scroll implementations frequently cause CLS spikes every time new content loads. Pagination doesn’t have this problem because new content loads on a fresh page, not mid-scroll. Check your Core Web Vitals in GSC. What’s your collection page CLS?
Priya: Checking… 0.18 on mobile. That’s “needs improvement” according to Google.
SDC SEO Brain: And that’s probably being caused by your infinite scroll. Every time new products load, the footer (or whatever’s below) jumps down. Users don’t consciously notice, but Google measures it. Since March 2024, Google replaced First Input Delay with Interaction to Next Paint (INP) as a Core Web Vital. INP measures responsiveness when users interact with the page. Infinite scroll implementations often have poor INP because the scroll handler is constantly firing, consuming main thread resources. Check your INP score too.
Priya: INP is 287ms on mobile. That’s in the “poor” range.
SDC SEO Brain: So your infinite scroll is hurting CLS and INP. Both are ranking factors. This is the hidden cost of infinite scroll that UX teams don’t see: it feels smooth to users but degrades measurable performance metrics that Google uses.
Priya: The UX team won’t care about Google’s metrics. They only care about user experience.
SDC SEO Brain: Here’s an argument they will care about: browser back-button behavior. When a user scrolls through 50 products on infinite scroll, clicks product 47, then hits the back button, what happens?
Priya: They go back to the collection page…
SDC SEO Brain: At what scroll position? Product 1 or product 47?
Priya: I’d have to test… Actually, I think it goes back to the top.
SDC SEO Brain: That’s the bfcache problem. Modern browsers use back-forward cache to instantly restore previous page state. But infinite scroll state isn’t preserved correctly in most implementations. Users who spent 2 minutes scrolling to find a product, clicked it, and hit back now have to scroll for 2 minutes again. That’s a UX problem your UX team should care about. Pagination preserves state. If a user is on page 4, clicks a product, hits back, they return to page 4. Infinite scroll breaks this fundamental web navigation pattern.
Priya: I never thought about that. Let me test… You’re right. Back button resets to the beginning.
SDC SEO Brain: So infinite scroll has three hidden costs: CLS degradation, INP degradation, and back-button UX breakage. Your UX team is optimizing for scroll smoothness while ignoring these other dimensions. A hybrid approach can mitigate some of this, but pure infinite scroll with no pagination fallback has real costs beyond SEO.
Priya: Okay, you’ve convinced me we need the hybrid approach. Walk me through implementation.
SDC SEO Brain: Here’s how it works: your collection page loads with, say, 24 products visible initially. At the bottom of that initial set, there’s a visible pagination element: “Page 1 of 15” with links to pages 2, 3, etc. Users who scroll past those 24 products trigger infinite loading of more products, but the pagination links remain in the DOM. Googlebot sees the pagination links, follows them, crawls page 2 which has products 25-48 with its own pagination links, and so on.
Priya: So users can still infinitely scroll, but Googlebot follows pagination links?
SDC SEO Brain: Exactly. The pagination becomes Googlebot’s crawl path while infinite scroll becomes the user’s browsing path. They coexist. The pagination links must be in the rendered DOM, which can be either server-rendered HTML or JavaScript-generated. Google’s WRS handles JavaScript-rendered links fine now. However, server-rendered links have two advantages: they’re discovered in phase one of crawling (before WRS queue), and they don’t depend on JavaScript executing without errors. For reliability and faster discovery, server-rendered pagination links are better. But JavaScript-rendered links work if your JS is solid.
Priya: How should I style the pagination so it doesn’t look ugly?
SDC SEO Brain: Don’t hide it with display:none or visibility:hidden. That risks being flagged as hidden content. Instead, style it as secondary navigation: smaller text, muted colors, positioned at bottom of initial product grid. Users who prefer to click through pages can use it. Users who prefer to scroll will scroll past it. Both interaction patterns work.
Priya: What about the canonical tags? Each paginated page needs its own canonical?
SDC SEO Brain: Self-referencing canonicals. Page 2 should canonical to page 2, not to page 1. If all paginated pages canonical to page 1, you’re telling Google pages 2+ are duplicates and should be ignored. Products unique to those pages lose their association with your collection page. This is the most common pagination SEO mistake. I’ve seen Shopify themes where some developer decided all pagination should point to page 1, effectively noindexing 90% of the catalog from category context.
Priya: Got it. Self-referencing canonicals.
SDC SEO Brain: There’s a subtle issue here too. When your infinite scroll loads products, does it change the URL to reflect scroll position? Some implementations update the URL to ?page=2, ?page=3 as users scroll.
Priya: No, the URL stays the same no matter how far you scroll.
SDC SEO Brain: Good in this case. URL-updating infinite scroll creates a different problem: the browser history fills with pagination entries. User scrolls to page 5, clicks a product, hits back, lands on page 5 infinite scroll state, hits back again, lands on page 4, and so on. History pollution. Your implementation avoids that.
Priya: What about the product order? Our infinite scroll shows products in different order than the pagination would.
SDC SEO Brain: How is that possible?
Priya: Infinite scroll uses our recommendation algorithm. Shows personalized order based on browsing history. Pagination shows default sort order.
SDC SEO Brain: That’s a problem. If infinite scroll shows products A, B, C, D and pagination page 1 shows products X, Y, Z, A, Google’s crawl doesn’t represent your actual inventory display. Worse, if some products only appear in the personalized infinite scroll order but never land on any paginated page, those products have no category page association for Googlebot. The sequences need to match, or at least overlap significantly.
Priya: So I need to change the infinite scroll to match pagination order?
SDC SEO Brain: Or vice versa. The key is consistency between what Google crawls and what represents your actual product organization. If you want personalization, apply it to both. If pagination is default sort, infinite scroll should be default sort (with optional user-triggered resort). The mismatch creates a different version of the site for users vs. crawlers, which erodes the value of the crawled version.
Priya: What about Shopify-specific issues? You mentioned there might be platform-specific risks.
SDC SEO Brain: Yes. Shopify exposes JSON endpoints that can get indexed if you’re not careful. Check if yoursite.com/collections/sectionals/products.json is publicly accessible. Also check /collections/sectionals.json. If those return 200 responses with product data, Google might index them as duplicate content of your actual collection pages.
Priya: Let me check… Both return JSON data. I can see all my products listed.
SDC SEO Brain: Block those in robots.txt immediately. Add these lines: “Disallow: /.json” and “Disallow: //products.json”. Shopify uses these endpoints for AJAX functionality, but they shouldn’t be crawlable. This is a common Shopify SEO leak that most store owners never discover.
Priya: Done. What else should I check?
SDC SEO Brain: Your collection.json endpoints were one issue. The other Shopify-specific issue is variant URLs. If your products have variants (size, color), Shopify can generate URLs like /products/sofa-name?variant=12345678. Those variant URLs can get indexed separately from the main product, creating duplicate content. Check GSC Coverage for “Duplicate without user-selected canonical” issues.
Priya: I see 847 URLs flagged as duplicates. Most are variant URLs.
SDC SEO Brain: Those need canonical tags pointing to the main product URL. Most Shopify themes handle this correctly, but custom themes sometimes miss it. Check your product template for canonical tag implementation.
Priya: Getting back to the infinite scroll fix. How many products per page is optimal?
SDC SEO Brain: Calculate based on four factors. First: mobile above-the-fold capacity. How many products fit on a mobile screen without scrolling? That’s your minimum, because that’s what Google definitely sees. Second: performance threshold. Each additional product adds images, DOM nodes, and JavaScript. Run PageSpeed Insights on your collection page with different product counts. Find where LCP exceeds 2.5 seconds. Stay under that. Third: competitive benchmark. Check what page-1 competitors show per page. If they show 36 and you show 12, you look thin by comparison. Fourth: category depth balance. Your 340-product collection can support 24 products per page across 15 pages. A 30-product collection can’t support the same density without creating empty pages.
Priya: For my sectionals collection with 47 products, what would you recommend?
SDC SEO Brain: 47 products across 2 pages (24 + 23) is clean. Alternatively, 16 products per page gives you 3 pages, which provides more pagination granularity. Either works. Avoid extremes: 8 products per page across 6 pages creates too many thin pages. 47 products on one page creates performance issues and defeats the purpose.
Priya: And the filter functionality? We have filters for material, color, size.
SDC SEO Brain: There’s an important distinction most people miss: single filtering versus faceted navigation. Single filtering means one filter active at a time: show me leather sofas, or show me gray sofas. Faceted navigation means multiple filters combined: show me leather sofas that are gray and under $2000. Single filters create linear URL growth. 10 materials = 10 additional URLs. Faceted navigation creates exponential URL growth. 10 materials × 8 colors × 5 price ranges = 400 additional URLs. That exponential explosion is where crawl budget gets eaten. How does your filtering work?
Priya: We have faceted navigation. Users can combine multiple filters.
SDC SEO Brain: Then you need a parameter strategy. Some faceted URLs are worth indexing: “leather sectionals” probably has search demand. Others aren’t: “leather gray sectionals under 2000 sorted by newest” has zero search demand and creates crawl waste. Identify which single-filter URLs have search volume and should be indexed. Create clean URLs for those: /collections/sectionals/leather instead of /collections/sectionals?filter.material=leather. Block faceted combinations with robots.txt or canonical them to the base collection.
Priya: That sounds like a big project.
SDC SEO Brain: It is, but it’s separate from the infinite scroll fix. Prioritize: first, fix the infinite scroll with hybrid pagination so your products are crawlable. Second, tackle faceted navigation parameter strategy. Third, optimize Core Web Vitals. Each improves your position independently.
Priya: Timeline for seeing results after implementing the hybrid pagination?
SDC SEO Brain: Depends on your domain authority and current crawl rate. Check GSC Crawl Stats for your daily crawl requests. High-authority sites (DR 50+) with good crawl rates might see ranking changes in 4-6 weeks after Google recrawls and reprocesses the collection pages. Mid-authority sites (DR 30-50) typically need 2-3 months. If your site is newer or lower authority, expect 4-6 months. The change enables discovery, but Google still has to choose to rank you higher based on the newly discovered content.
Priya: We’re around DR 42 according to Ahrefs.
SDC SEO Brain: Mid-authority range. Expect 2-3 months for measurable impact. You can accelerate discovery by submitting an updated sitemap that includes your paginated URLs. But ranking improvements depend on Google processing everything and deciding the additional product context improves your page’s relevance for category queries.
Priya: One more thing. I read somewhere that infinite scroll is better for engagement. Is that true?
SDC SEO Brain: That claim conflates engagement metrics with user satisfaction. What infinite scroll definitely does: increases time on page (more content to view) and can increase scroll depth metrics. What it doesn’t guarantee: actual user satisfaction or conversion. Research from Baymard Institute found that infinite scroll on e-commerce category pages increased time-on-page but decreased product findability. If someone searches “gray leather sectional,” lands on your collection page, and has to scroll through 80 products to find leather options because filtering is hidden, they experience friction even with infinite scroll. The scroll mechanics work fine. The findability is broken. Good filtering UI affects conversion more than scroll behavior does.
Priya: Our filters are behind a hamburger menu on mobile.
SDC SEO Brain: That’s a problem beyond SEO. If filters are hidden, users scroll hoping to stumble on what they want instead of navigating directly. That’s friction disguised as discovery. For SEO, hidden filters mean filtered URLs aren’t discoverable either. Visible filters with clear links create crawl paths to filtered pages. Hidden filters mean Googlebot never finds /collections/sectionals?filter.material=leather unless it’s in your sitemap or linked elsewhere.
Priya: Should I add filtered URLs to sitemap?
SDC SEO Brain: Only if you want them indexed. Sitemap is a discovery signal, not an indexing directive. Adding URLs tells Google “these exist, please crawl them.” If you add 500 filter combination URLs, expect Google to crawl them. If most are thin pages with 1-2 products, you’re wasting crawl budget on low-value pages.
Priya: How do I identify which filter combinations are thin?
SDC SEO Brain: Export your filter combinations programmatically. For each, count how many products match. Any combination with fewer than 5-10 products is probably too thin to merit indexing. “Leather sectionals” with 12 products is worth indexing. “Leather sectionals with gold legs under $2000” with 1 product is not.
Priya: This all makes sense. Final question: should I worry about our competitors copying whatever we build?
SDC SEO Brain: Competitors copying good implementation is a non-issue. SEO best practices are table stakes, not competitive advantages. If they have good pagination and you don’t, they’re already ahead. If you both have good pagination, you compete on other factors: product quality, content depth, backlink authority, brand recognition. Pagination implementation is infrastructure. It doesn’t differentiate. What differentiates is what you do with the properly crawlable pages afterward. This is game theory: when everyone follows the same playbook, the playbook stops providing advantage. You need differentiation in content, not just technical implementation.
FAQ
Q: Does Googlebot actually scroll web pages?
A: No. Googlebot’s Web Rendering Service (WRS) executes JavaScript and captures the final DOM, but does not simulate scroll events. Content triggered by scroll position or scroll event listeners won’t render. Note that Intersection Observer API behaves inconsistently: some implementations may trigger during WRS render even without scrolling. Always test your specific implementation using GSC’s URL Inspection tool to see exactly what Google captures.
Q: Can I hide pagination links from users while showing them to Googlebot?
A: No. Showing different content to Googlebot than to users is cloaking, which violates Google’s guidelines. Pagination links should be visible to both users and bots. Style them as secondary navigation (smaller text, bottom of page, muted colors) so users who prefer scrolling can ignore them. The links must be genuinely visible, not hidden with display:none or visibility:hidden.
Q: Should paginated collection pages use self-referencing canonicals or all point to page 1?
A: Self-referencing canonicals. Each paginated page should canonical to itself (page 2 canonicals to page 2). If all pages canonical to page 1, you’re telling Google pages 2+ are duplicates and should be ignored. Products unique to those pages lose their association with your collection page. This is the most common pagination SEO mistake.
Q: Does Google still use rel=prev and rel=next for pagination?
A: No. Google announced in 2019 they hadn’t used these signals for years and officially deprecated them. Don’t implement rel=prev/next expecting SEO benefit. Focus on actual link structure, proper canonicalization, and ensuring paginated pages have unique, valuable content.
Q: How does infinite scroll affect Core Web Vitals?
A: Infinite scroll commonly degrades two Core Web Vitals. CLS (Cumulative Layout Shift) increases when new content loads and pushes existing content down. INP (Interaction to Next Paint, which replaced FID in March 2024) degrades when scroll handlers consume main thread resources. Check GSC Core Web Vitals report for your collection pages specifically, and test with PageSpeed Insights during scroll events.
Q: Why does infinite scroll break the browser back button?
A: Modern browsers use back-forward cache (bfcache) to instantly restore previous page state. Most infinite scroll implementations don’t preserve scroll position correctly in bfcache. When users scroll through 50 products, click one, then hit back, they return to product 1 instead of their scroll position. This forces users to re-scroll, creating friction. Pagination preserves state because page numbers are discrete URLs stored in browser history.
Q: How many products should each paginated page show?
A: Calculate based on four factors: (1) Mobile above-the-fold capacity, since Google uses mobile-first indexing. (2) Performance threshold: LCP should stay under 2.5 seconds and initial DOM under 1.5MB. (3) Competitive benchmark: match or exceed what page-1 competitors show. (4) Category depth: main categories support more products than narrow subcategories. For furniture e-commerce, 16-24 products per page is typical, but validate with PageSpeed Insights for your specific implementation.
Summary
Infinite scroll and SEO visibility are fundamentally opposed. Users want seamless browsing without page clicks. Google needs discrete, crawlable URLs. There’s no implementation that fully serves both. The solution is a hybrid approach where both interaction patterns coexist.
Googlebot’s Web Rendering Service doesn’t scroll. WRS executes JavaScript and captures the rendered DOM, but never triggers scroll events. Content that loads on scroll doesn’t exist to Google. A 340-product collection with 4 products in initial mobile viewport appears as a 4-product collection to search engines. Critical nuance: WRS queue times range from hours to weeks, so even visible content isn’t processed instantly.
Mobile-first indexing means mobile viewport counts. Google primarily sees your mobile rendering. If mobile shows 4 products above the fold and desktop shows 8, Google sees 4. Always test and optimize for mobile viewport capacity.
Phantom pagination solves nothing. Adding ?page=2 URLs that work but aren’t linked anywhere is useless. Google discovers pages through links, not by guessing parameters. If pagination exists only in code but not in crawlable HTML links, Google never finds it.
Self-referencing canonicals are mandatory for pagination. Each paginated page must canonical to itself. If all pages point to page 1, you’re telling Google pages 2+ are duplicates. Google ignores them, along with all products unique to those pages. This mistake is extremely common.
Infinite scroll and pagination sequences must match. If infinite scroll shows products in personalized order while pagination shows a fixed order, Google’s crawl doesn’t represent your actual inventory. Products that appear only in personalized scroll positions might never appear on any paginated page, making them invisible to category-level ranking.
Infinite scroll degrades Core Web Vitals. CLS increases when new content loads and pushes existing content down. INP (which replaced FID in March 2024) degrades when scroll handlers consume main thread resources. These are ranking factors that infinite scroll implementations commonly harm.
Infinite scroll breaks browser back-button behavior. Bfcache doesn’t preserve infinite scroll state correctly. Users who scroll through 50 products, click one, and hit back return to product 1, not their scroll position. This is a UX problem that UX teams focused only on scroll smoothness often miss.
Single filters versus faceted navigation require different strategies. Single filters (material=leather) create linear URL growth. Faceted navigation (material=leather AND color=gray AND price=under-2000) creates exponential URL growth. The exponential case requires aggressive canonicalization or robots.txt blocking to prevent crawl budget exhaustion.
Platform-specific risks exist. On Shopify, check whether your collection.json or products.json endpoints are publicly indexed. These can create duplicate content issues if Google crawls the raw JSON responses. Block in robots.txt if accessible.
Timeline varies by domain authority. High-authority sites (DR 50+) might see ranking changes in 4-6 weeks. Mid-authority sites (DR 30-50) need 2-3 months. Lower authority sites with slow crawl rates might need 4-6 months. Check GSC Crawl Stats for your baseline crawl frequency.
Sources
- Google Search Central: Infinite scroll search-friendly recommendations (https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading)
- Google Search Central: Consolidate duplicate URLs (https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls)
- Google Search Central: Interaction to Next Paint (INP) (https://developers.google.com/search/docs/appearance/core-web-vitals)
- Google Webmaster Central Blog: Official pagination guidance (https://developers.google.com/search/blog/2011/09/pagination-with-relnext-and-relprev) [Note: deprecated 2019]
- Google Search Central: Large site crawl budget management (https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget)
- Web.dev: Cumulative Layout Shift (https://web.dev/cls/)
- Baymard Institute: E-commerce UX research (https://baymard.com/)