Search Dribbble for "dashboard" and you get a wall of thumbnails. Useful if you are hunting for a direction, and completely ordinary. Every site with a library has a page like it.
What is less ordinary is that Dribbble has filed that page with Google.
We pulled the sitemap index on 29 August 2026 and worked through all 226 child files. The bulk is what you would expect from a design portfolio: individual shot pages, millions of them, each one a piece of work somebody uploaded. But the second and third largest families in the whole index are not profiles, not jobs, not the blog. They are tag archives and internal search results—pages no human sat down and made.
Put those two families next to the designer profiles Dribbble bothers to submit and the strategy shows up as one ratio: 26.7 machine-generated listing pages per profile. That is the story, and the rest of the site is built to survive it.
Results at a glance
Dribbble's sitemap is dominated by design shots, as you would expect. The surprise is behind them: tag archives and internal search pages are 11.8% of everything submitted, while the profiles of the designers who supply the work are under half a percent.
Our first pass estimated the largest family rather than counting it; a second pass downloaded every child file and counted every entry, and landed on the same total to the URL. Both passes agree, and the ratio holds.
What the sitemap actually holds
The index is unusually tidy. Shots live in 189 files, tags in 19, search in 8, everything else in a single file each. Every full file holds exactly 50,000 entries and the last in each family holds the remainder—a discipline that made the count easy to check twice.
The composition is lopsided the way a marketplace usually is. Shots are 87.4% of the index. The ordering below is the interesting part: tags outrank search, search outranks profiles by a wide margin, and everything Dribbble writes or curates by hand fits inside a rounding error.
The search pages are the point
A search results page is generated the moment somebody types something. It costs nothing and exists in whatever quantity your query log dictates. Most sites treat those pages as plumbing and keep them out of the index deliberately, because a crawler that follows them can wander forever.
Dribbble goes the other way. The search family is submitted in full, with more inside the services file, and robots.txt blocks that path for exactly one crawler—PetalBot—leaving Googlebot explicitly free to walk every one. This is not an accident of configuration. Somebody decided these pages should be crawlable and then listed them.
The logic is easy to reconstruct. A designer hunting for a direction types the same phrases people type into Google, and if the query page satisfies that search it may as well rank. The cost is crawl budget spent on pages nobody wrote, and a long tail of near-duplicates drawn from one pool of shots.
The evidence of that cost is already inside the sitemap. Slug collisions have produced thousands of repeated entries—"add ons" and "add-ons" collapsing to one URL, filed more than once. Small against 10.8 million, but the fingerprint of pages minted by a rule rather than chosen by a person.
A perfect audit and what it means
We ran the domain through our own website audit expecting the usual crop of warnings any site this size accumulates. It came back at 100. All 123 checks passed—on-page, technical, speed, mobile—with nothing critical, no warnings, and not a single notice.
That is the first perfect score in this series. Sites with far less to serve came in lower—the best before this was 91.
Read as a report card, that number flatters. Read as a fact about how the site is built, it explains the rest of the article. A site submitting more than a million auto-generated listing pages cannot afford sloppiness anywhere else. The margin for error on a page no editor reviewed is zero, so the machinery around it has to be flawless by default. The perfect audit is not a trophy. It is the price of admission.
A second piece of engineering is worth naming, because it quietly breaks other people's crawls. The sitemaps sit on a separate host and answered every request first time, no rate limiting, no redirects. The pages do not: a plain HTTP client gets a bot-challenge stub. We opened a real browser to confirm shot URLs resolve. They do. Anyone auditing this domain with a command-line fetcher alone would call the site broken.
Links arrive at the front door
Our backlink analyzer puts the domain at rank 97, higher than every site in this series except two, and counts 528,375 referring domains. Large in absolute terms, small against the page count: 0.0489 referring domains per page, near the bottom of this series, above Levels.fyi and below Rotten Tomatoes.
That ratio is the honest picture of what a page-heavy strategy does to your averages. Nobody links to a search page for "dashboard"; they link to a shot, a designer, or the homepage. Authority pools at the top and spreads thinly beneath, and every new listing page dilutes it further. Dribbble can afford that because its authority is enormous. A smaller site copying the tactic ends up with thin pages and no strength to lend them.
Why the ratio is not madness
It would be easy to file this under index bloat and move on. Worth resisting, because the ratio is defensible in a way most page farms are not.
A tag archive on Dribbble is not empty. It is backed by real uploaded work, refreshed constantly, organised by a vocabulary designers use, and a search page is the same content sorted differently. The pages are machine-assembled but the substance underneath is not—the distinction Google has spent years trying to draw, and the reason this looks less like spam than the raw count suggests.
The denominator deserves scrutiny. Fewer than 48,000 profile URLs are submitted, and a handful of those are hiring landing pages living at the root. Dribbble's membership is far larger. So the ratio is not "machine pages versus people"—it is where Dribbble spends its sitemap slots. It has decided a query page beats most members' profiles.
Copy this in an afternoon
You do not need 10 million pages to borrow the thinking here. You need to be deliberate about which generated pages you file and ruthless about the rest.
1. List your sitemap by family, not by total. Split every URL by path pattern and count each bucket. Most teams know their total and not their mix. The mix is where the decisions are.
2. Decide about search and tag pages on purpose. Either they are good enough to rank and you submit them, or they are plumbing and you keep them out. The failure mode is neither—pages that leak in by default and nobody owns.
3. Deduplicate your slugs. Dribbble's collisions come from different phrases resolving to the same URL and being filed more than once. Normalise before you generate, and check your own sitemap for repeated entries.
4. Get the technical baseline to zero defects first. A generated page has no editor to save it. Fix the site-wide layer before you scale anything, and re-audit after.
What you cannot copy
The inventory is contributed. Dribbble did not create the millions of shot pages that give its tag and search archives something to show; designers uploaded them, one at a time, and keep doing it. No script reproduces that. Every generated listing page is a new arrangement of work other people supplied for free. Without the supply, the tactic produces empty rooms with good signage.
And here is what we could not check:
Whether these pages carry an index directive. We proved the intent at the sitemap and robots.txt layer only. The pages answer plain HTTP clients with a bot challenge instead of HTML, so we could not read page-level meta robots at scale. Some of these URLs may be submitted and then told not to be indexed.
Our first count was partly an estimate. The largest family was too big to download politely, so the first pass assumed the standard per-file cap and counted only the tails. A second pass fetched all 226 files in full and counted every entry, reaching exactly the same total. We report it as verified for that reason, but the first number was an estimate.
The total counts entries, not unique URLs. Duplicate slugs make the deduplicated figure slightly lower. We publish both in the FAQ rather than picking the flattering one.
Our own backlink tool does not reconcile. Its dofollow and nofollow figures add up to more than the total backlinks it reports for the same domain. The gap is around 6 million, but it is our defect and not Dribbble's, so we lean on referring domains and the split rather than the headline total.
We cannot see the outcomes. No traffic, no index coverage, no rankings. We can tell you what Dribbble asks Google to crawl, not how much of it Google kept.
Dribbble's perfect score is what makes its page volume survivable. Run the same 123 checks on your own domain and see which part of the baseline is holding your generated pages back.
- On-page, technical, speed and mobile in one pass
- Every failed check named, with the fix
- Re-run it after changes to confirm the repair
Frequently asked questions
How many URLs are in Dribbble's sitemap?
10,811,977 entries across 226 child sitemap files, measured on 29 August 2026. Our first pass estimated the largest family from a sample of files; an independent second pass downloaded all 226 children and counted every entry, returning the identical figure.
What is the full composition?
Shots 9,447,790 (87.38%), tag archives 921,830 (8.53%), internal search 351,145 (3.25%), designer profiles 47,657 (0.441%), services 40,475 (0.374%), blog 2,073, design teams 588, job directories 229, hiring landing pages 110, job listings 58, category pages 18, product pages 3, and a single resources page.
How many internal search URLs are there really?
351,145 in the search family, plus 1,289 more filed inside the services sitemap, for 352,434 in total. There are also duplicates: 2,296 repeated tag URLs, 1,318 repeated search URLs and 4 repeated services-search URLs, so the deduplicated site total is 10,808,359.
Does Google actually index these pages?
We cannot say. What we can show is that they are submitted in the sitemap and that robots.txt disallows the search path for PetalBot only, leaving Googlebot permitted. The pages themselves sit behind a bot challenge, so we could not read their meta robots tags at scale.
Is 47,657 the number of designers on Dribbble?
No, and this matters. That is the count of profile URLs submitted in the sitemap, not the membership, which is far larger. 7 of those entries are hiring landing pages rather than profiles, and 588 team profiles are filed separately. Including teams, the listing-page ratio is 26.4:1 rather than 26.7:1.
What does the backlink profile look like?
Domain rank 97, with 528,375 referring domains. The split is 92,443,557 dofollow and 13,512,669 nofollow, or 87.2% dofollow. Our tool also reports 99,962,513 total backlinks, which is around 6 million short of what its own dofollow and nofollow figures add up to—a discrepancy in our tool, so treat referring domains as the reliable number.
How does that compare with the rest of the series?
0.0489 referring domains per page. That sits between Levels.fyi at 0.026 and Rotten Tomatoes at 0.063, and far below calculator.net at 143 across only 222 pages. Page-heavy sites always land at the bottom of this measure; it is a description of the strategy, not a verdict on it.
What exactly did the audit score?
100 out of 100, with 123 checks passed and nothing flagged: on-page 25/25, technical 67/67, speed 29/29, mobile 2/2. No critical issues, no warnings, no notices. It is the first perfect result in this series; the previous best was 91.
The temptation with a site like this is to score it. 10 million pages assembled by a rule sounds like a cautionary tale until you look underneath and realise the rule is drawing on genuine material.
The more useful reading is about allocation. Dribbble has a finite amount of attention to ask for, and spends a large share of it on pages that answer a query rather than pages that introduce a person. A deliberate bet, and the flawless technical baseline keeps it from collapsing under its own weight.
If you generate pages at any scale—tags, filters, search, location pages—the lesson is not the ratio. It is the order of operations: fix the foundation until nothing is flagged, then decide, family by family, which generated pages deserve a crawl. Our free website audit runs the same checks that returned 100 here.
Measured on 29 August 2026. Sitemap composition taken from dribbble.com's sitemap index and all 226 child files; the first pass estimated the largest family from a sample, and an independent second pass counted every entry in every file, reaching the same total. Counts are raw entries unless stated as deduplicated.
Backlink and audit figures come from the free UNmiss Backlink Analyzer and Website Audit, run against dribbble.com the same day and reported as returned, including the discrepancy noted in the FAQ. Detail pages were checked in a real browser because the site returns a bot challenge to plain HTTP clients.