How a Yupoo storefront gets verified here, step by step
Every factual sentence on this index traces back to one measured fetch of the storefront, on one date, kept as evidence you can ask us about. This page is that method written down, including the parts that are imperfect.
The audit window
The current figures come from a single sweep on 2026-10-27. Within that window each host was requested once, and the per-host report, the visible-text snapshot and the row in the aggregate table were written from that one response. Nothing in the table is a blended average across months, and nothing was quietly back-filled from an older crawl.
The population was not assembled by guessing store names. It was built keyword-first: the eighteen search terms buyers actually type were collected, their top-result host sets harvested, and the pool expanded with same-tier storefronts until each keyword carried a twenty-site set. That is why the audit covers 161 hosts rather than the 19 profiles we publish: the rest are the neighbourhood a buyer lands in when they search a seller by name.
Of the 161 audited hosts, 149 are storefronts on the album platform itself; the remainder are directories, mirrors,
agents, community pages and the platform host. Retained evidence: data/sitefacts.json (161 records),
research/sites (161 per-site reports), research/serp (18 keyword files plus
data/serp.json), src/data/store_evidence.json (18 measured seller profiles) and
data/keyword_metrics.json (18 rows).
What we fetch, and where you can see it
| Metric | How it is measured | Where it is visible |
|---|---|---|
| HTTP status and final URL | One GET per host, redirects followed, 30 second timeout, desktop Chrome user agent, Accept-Language en-US, issued through a residential proxy because datacentre ranges get throttled. | Status pill on each profile; the status column of the data table. |
| Response time (recorded as ttfbMs) | Elapsed time until the response body was fully read. It is a floor for first-byte latency, not a lab measurement, and we label it that way. | Data table; “measured” bullets on profiles. |
| HTML weight | Byte length of the response body only. Sub-resource weight (CSS, images, scripts) is not summed, so this under-states a real page load. | Data table; profile facts. |
| Images on the first screen | Count of img elements in the served HTML before any scrolling or script runs. | Data table; the “renders N product images” line on profiles. |
| Images without ALT text | img elements with a missing or blank alt attribute in the same pass. | Data table; profiles quote it as the reason albums are invisible to search. |
| Lazy loading and srcset usage | Presence of loading="lazy" and srcset attributes, counted, not sampled. | Design notes on peer comparisons. |
| Folder and navigation text | Anchor labels between 1 and 30 characters inside the first nav or header element, de-duplicated, first eighteen kept. That string set is how we read a store’s own product families. | The “what it carries” block on every profile. |
| Contact channels | Substring scan of the raw HTML for whatsapp, wa.me, telegram, t.me, wechat, instagram, discord, tiktok, youtube, facebook and pinterest. Presence only. We do not message every number on every store. | The contacts block on profiles, always attributed to the page that prints it. |
| Structured data types | Every application/ld+json block parsed, @graph arrays walked, @type values collected. | Profile facts and the data table’s schema column. |
| Visible text volume | Runs of two or more Latin letters in the extracted page text. Chinese characters are flagged separately, not counted, so a Chinese-only album reads as near-empty. | Data table; the argument in the guides about why albums do not rank. |
| Design and stack signals | Hex colours minus near-greys, first font-family declarations, and framework signatures such as Next.js, Nuxt, WordPress, Shopify, Wix, Webflow and Cloudflare challenge scripts. | Peer comparison notes and the layout variety on seller pages. |
| Feature heuristics | Text presence of cart, search, filter, review, size guide, order tracking, currency, QC and inquiry wording. Presence of a word is not the presence of a feature, so these are treated as hints. | Catalog pages and the album-versus-shop tables in the guides. |
| Search visibility | Bing’s English index, up to three result pages per keyword, maximum twenty distinct hosts kept per keyword, each row labelled bing-exact or bing-variant. Autosuggest came from Bing’s osjson endpoint with an en-US market. | Keyword notes on profiles; the 18-row metric view in the data table. |
How a host is classified
The class decides what we are allowed to claim about a host. A seller gets a profile. A peer gets a measurement. A directory, an agent or a community page gets quoted only as evidence that somebody else says something, never as fact.
- seller
- The storefront a tracked keyword is named after, and the reason the page exists. Ten hosts in the audit carry this class: the profile must have been fetched, its folders read and its printed contacts recorded before it gets the label.
- peer
- Another Yupoo storefront in the same tier, pulled in to show what the neighbourhood looks like. 127 of the audited hosts are peers. They are measured the same way but never promoted, because a peer is context, not a recommendation.
- directory
- A third-party site that lists sellers for a living, including the public profile pages we cross-checked host strings against. Classified separately because a directory describes an album; it is not one.
- aggregator
- A mirror that re-publishes album content as its own product or category pages. The tell is hundreds of templated landing pages pointed at the same hosts.
- agent
- A buying agent or benchmark storefront that purchases on your behalf and charges a fee plus shipping markup. One agent host is audited as a reference point for fee comparison.
- community
- Reddit, YouTube, Instagram, Discord and Linktree results that rank for supplier keywords. Useful for sentiment, never treated as a source of fact about a store.
- serp
- An organic result we harvested but have not classed yet. Twenty hosts sit here. A host keeps the class of the pool row that first referenced it, and a row carrying a recorded search rank overrides that class.
The Bing-only limitation, stated plainly
Position and visibility data on this site comes from Bing’s English index. That is not a preference and it is not a shortcut. Google refuses scripted result capture: the query returns a JavaScript wall rather than organic rows to a plain HTTP client. DuckDuckGo rate-limited the proxy we were using for this collection, mid-run, which made its result sets inconsistent day to day. Bing answered, kept a stable result set across three pages, and let us store every raw response.
The consequence you should read into the data: a host that ranks on Bing but not Google appears here, and one that ranks on Google but not Bing does not. Bing’s index is smaller and its storefront coverage for Chinese album hosts is patchier, so we treat organic rows as demand evidence, not as authority evidence. Where a page says a keyword “has no commercial result occupying it”, that is a statement about the Bing top twenty and nothing more.
Each harvested row carries an evidence label. bing-exact means the row appeared while paging the exact target phrase.
bing-variant means it came from a long-tail reformulation of the same intent. Rows are capped at twenty distinct hosts
per keyword so a single prolific mirror cannot fill a set, and duplicates are dropped by host rather than by URL, because album
stores republish the same folder under many paths.
Update cadence and how corrections enter the record
The full audit re-runs monthly. Pages carry an updated date so you can tell at a glance whether you are reading this month’s fetch or last quarter’s; index and data pages say it in the hero, profiles say it beside the measurement, guides say it in the byline. A re-audit rewrites numbers, statuses, folders and contacts. It does not silently rewrite an opinion: if a description changes in substance, the change and its reason are noted on the page.
Reader corrections are the second input and, in practice, the faster one. A buyer who reports a new WhatsApp number or a moved host usually beats the monthly sweep by weeks. Corrections follow the schedule in the correction policy, and the details a useful report carries are listed there: host string, what changed, the date checked, and the served page if you have it. Questions about reuse of the data itself go to editorial@yupoo.rest.
Known limitations, listed rather than footnoted
- Positions are Bing’s, not Google’s. Google blocks scripted result capture and DuckDuckGo rate-limited this proxy during the window, so no claim about Google ranking is made anywhere on this site.
- One fetch per host. A storefront that intermittently refuses connections can read as dead on a bad hour and live on a good one.
- No JavaScript rendering for the measured pages. A shop that builds its folder list client-side would report fewer links and fewer images than a browser would show.
- Gated albums are not logged into. Password folders exist on many stores; we describe that they are gated, not what is inside.
- Prices are not verified. Where a price appears in an album title we quote the title; we do not confirm the number with the seller.
- Contact channels are presence, not reachability. A printed WhatsApp number is evidence the page shows one, not that a human answered it.
- No orders were placed to test these listings, so nothing on this site is a claim about what arrived.
- Chinese and Spanish text are outside the word count, which is why several storefronts look emptier in our table than they are in WeChat.
- Two hosts could not be audited at the TLS layer, one of them a malformed host string in our own pool that has since been removed.
- Brand names in a catalogue are the store’s labelling. We reproduce it to describe the assortment; that is not a recommendation, and the legal exposure of ordering a trademarked item is yours.
Method questions
The three things people ask us to defend when they check our numbers.
Why not just use a paid SERP API for the ranking data?
Because we would then be quoting a black box. The Bing collection is small, reproducible and stored as raw JSON in research/serp, one file per keyword, so anyone can re-run the arithmetic and disagree with a specific row instead of the whole table.
How does a storefront get marked delisted rather than deleted?
When every host we hold for a store returns HTTP 404 across two consecutive audits. TopGoosey is the current case: topgoosey.x.yupoo.com and topgoosey1.x.yupoo.com both returned 404, so the profile stays live with the status, the checked hosts and the four outerwear sellers that absorbed that demand.
What is the weakest part of this method?
The single-fetch snapshot. Storefronts here change folders and contacts weekly, so a profile is accurate for its date and stale afterwards, which is why the date is on the page rather than in a footer nobody reads.
A catalogue you can verify for yourself
The listing partner publishes per-product pages with codes and thumbnails, so you can compare a folder name in an album against a page that stays where you left it. That is the structure this index measures and cites.