The old marketplace showed a near-empty shell to people and AI, and a second, hidden app to Google. The new platform serves one real page to everyone — and it wins every single comparison: speed, accessibility, SEO, AI readiness, social sharing, and the architecture underneath.
Same Lighthouse version, same pages, same three-run protocol, same third-party exclusions applied to both platforms. V2 wins all six page / form-factor match-ups — and turns three categories into perfect scores.
Performance values are the mean of the three per-page Lighthouse aggregates. The controlled protocol excludes the shared consent/chat/analytics stack from both versions — the same third parties, removed from both sides. SEO for V1 spans 66–69 across pages.
V1 is really two applications behind one URL: browsers and AI agents get an empty SPA shell, while a separate server-rendering stack serves Google alone. V2 is one Nuxt application that answers everyone with real content — and dresses itself per brand from the request host. Pick an audience:
V1's early first paint is a spinner — the content arrives much later, client-side. The number that matters is LCP: when the main content is actually on screen. Watch the same three pages render on both platforms, at real relative speed:
Mobile product remains the honest weak spot: 7.71 s LCP (score 70) — still 49% faster than V1's 15.25 s, and the main gallery image is a known, targeted fix.
On V1, being discoverable required an entire separate system: a dedicated Node service in its own repo, triggered over HTTP, writing XML files to S3 per shop, wired back through HAProxy. Today, on production V1, robots.txt answers 403 and the sitemap URLs return HTML. On V2, discovery is a native part of the application — identical in every environment.
| Surface | V1 · old | V2 · new |
|---|---|---|
| robots.txt | 403S3 AccessDenied XML instead of a crawler policy | 200valid policy — search allowed, AI-training bots opted out |
| Sitemap index | HTMLsitemap URLs return the SPA shell, not XML | 200valid XML — 1 pages map + 348 monthly product maps |
| Product URLs | 0no first-party discovery surface at all | 383in the July map alone · ≈84,158 + 52,243 localized URLs at full scale |
| Canonicals & hreflang | partialonly inside the hidden crawler renderer | every pagerequest-aware canonical + 5-locale alternates in universal SSR |
| Lighthouse SEO | 66–69measured on the browser SPA | 100on all six page / form-factor runs |
Answer engines are becoming a real acquisition channel — and they don't execute JavaScript apps to guess a price. On V1, GPTBot and PerplexityBot receive the same empty shell as browsers, and every AI surface returns 404. V2 gives an agent full visibility of the platform: native Markdown for every route, a guided llms.txt map, structured data on every page, and complete product indexing through the sitemaps. The rubric below scores five criteria by weight — then each one is broken down.
The single biggest criterion: can any agent read the page at all? V1 only renders content for Google's hidden crawler app — browsers, GPTBot and Perplexity get an empty shell. V2 serves one complete SSR document to every user agent, so the page an AI parses is exactly the page a human sees. No cloaking, no parity risk.
V1's JSON-LD exists only inside the Google-only renderer. V2 emits a full Schema.org graph in universal SSR: WebSite, WebPage, Organization and ImageObject sitewide; Product, Offer and BreadcrumbList with resolved labels on every product — generated from the same data source as the visible page, so it can never drift.
V1 has literally nothing: llms.txt, llms-full.txt and every .md mirror return 404. V2 detects AI agents and serves native Markdown for every route, publishes a machine-readable site map in llms.txt and a 181.6 KB full-content index. The two points deliberately left: volatile auction data stays in per-product .md rather than one giant stale index.
V1 production blocks itself: robots.txt answers 403 and sitemaps return HTML. V2 pairs a valid crawler policy with 349 sitemaps covering the entire product corpus, request-aware canonicals and five-locale hreflang on every route — the whole discovery chain works end to end.
To learn a V1 product's price, a model must execute an SPA or dig through ~800 KB of crawler markup. A V2 product is 3–4 KB of Markdown: title, price, characteristics, dates, seller, canonical link. Two points remain: some pages still carry navigation context an agent must skip.
Everything shown is the live deployed response, captured as-is. llms-full.txt serves 181.6 KB of indexed page content; volatile product data is deliberately left to per-product Markdown + the XML sitemaps, which is the safer design for auction inventory.
A browser needs the whole page — markup, styles, hydration state. An agent only needs the facts. V2 serves both from the same URL: ask as a browser, get the full document; ask as GPTBot (or append .md), get pure Markdown. Below, the two real responses for the same product. Race them — find the price:
Both payloads are the live captured responses for product agora-405863 on build 849 (token estimate: ~4 characters per token). The Markdown keeps everything that matters — title, price, characteristics, dates, seller terms, images and the canonical link back to the page — and drops everything that doesn't.
Accessibility is not a page-by-page patch job on V2 — semantic structure, naming and contrast are owned once, by the shared component system. The automated result speaks for itself:
An automated 100 is a strong floor, not a conformance claim: keyboard traversal, screen readers, zoom/reflow and reduced-motion are on the checklist for the full 50-product study.
One honest finding remains: with the shared third-party stack enabled, V2 loses 8 desktop and 23 mobile Lighthouse points (+1.25 MB, +28 requests on every cold page). The marketplace is no longer the bottleneck — the tag stack is. The plan attacks exactly that, in order — and step 2 has already shipped:
CookieConsent v3 — MIT-licensed, a few kilobytes, fully themeable — replaces the tool whose own banner becomes the page's largest paint (~16 s LCP on throttled mobile). Tracking and telemetry stay, consent-gated exactly as today; what disappears is the cost of the tool itself, which currently butchers every metric it sits in front of. Includes a one-for-one legal review of the consent taxonomy.
Done. GTM is now an optional runtime off the critical rendering path: application code pushes events immediately into a private queue, consent stays the trigger for capture, and once granted the container is only requested after web-vitals finalizes the initial LCP. No event is lost — only enqueued — and an untouched Lighthouse run never fetches, parses or executes GTM at all.
The chat widget currently ships over 0.5 MB and ~0.095 CLS into the critical path of every visit. It moves to interaction-or-idle loading, with reserved geometry for the launcher so nothing shifts when it arrives.
Product scores 70 on mobile with a 7.71 s gallery-image LCP — 49% faster than V1, but behind the 88 of home and catalogue. Prioritizing the first gallery image is a focused, known fix — not an architecture problem.
The final validation: 25 legacy + 25 canvas-rich products — metadata completeness, structured-data validity, content parity — plus the full crawler matrix re-run against the production edge, without UAT's Basic Auth in the way.
Steps 1–3 recover the points the tag stack costs today — none of them touch marketplace code, and the GTM half is already done. The application-controlled numbers in this report are what production users get once the stack is cleaned.
Every shared link is now a branded storefront.
Paste a marketplace link in LinkedIn, Slack or WhatsApp. On V1 you got a bare logo — or a raw warehouse photo with no context. V2 renders a designed 1200×630 card live for every page, in the right brand, with title, category and price composed in. Try any combination — every V2 image below is the deployed renderer's real output: