VARNI STOREFRONTS · QUALITY AUDIT · 2026-07-12
Live site: https://website-21.varnijewels.com · Design reference: lucirajewelry.com
Audited across three dimensions: launch readiness (functionality, SEO, performance, security, accessibility, analytics, brand), mobile QA (real device emulation, touch), and desktop QA (1920/1440/1366, hover + keyboard). Report-only — no purchase was completed.
Launch-readiness scoring. Infra-only items are marked MANUAL and left unscored.
| Category | Score | Verdict | Defects |
|---|---|---|---|
| Core functionality | 35 | fail | 6 |
| Performance & Core Web Vitals | 58 | warn | 2 |
| Technical SEO | 25 | fail | 7 |
| Security | 30 | fail | 5 |
| Frontend & responsive | 68 | warn | 3 |
| Backend (externally observable) | 60 | warn | 2 |
| Analytics & tracking | 5 | fail | 1 |
| Accessibility | 85 | pass | 2 |
| Brand consistency | 15 | fail | 7 |
| Marketing readiness | 30 | fail | 4 |
| Monitoring & maintenance | — | manual | 1 |
Lighthouse CLI, mobile emulation defaults.
| Page | formFactor | performance | accessibility | bestPractices | seo | lcp | cls | tbt | fcp | speedIndex | tti | url |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| home | mobile | 0.73 | 0.95 | 0.96 | 0.92 | 4.9 s (score 0.28) | 0 (score 1) | 0 ms (score 1) | 2.9 s (score 0.54) | 5.5 s (score 0.54) | 4.9 s (score 0.78) | — |
| pdp | mobile | 0.55 | 0.87 | 0.96 | 0.92 | 12.5 s (score 0) | 0 (score 1) | 30 ms (score 1) | 8.6 s (score 0) | 20.0 s (score 0) | 12.5 s (score 0.14) | https://website-21.varnijewels.com/products/05-carat-14k-rose-gold-igi-certified-lab-grown-round-cut-diamond-engagement-ring-with-half-pave-band-for-women-e-f-color-vs1-vs2-clarity |
40 findings across functionality, SEO, security, performance, accessibility, analytics and brand consistency.
Navigating to /rings, /earrings, /bracelets, /necklaces, /pendants, /bestsellers, /solitaire(s), /9kt-collection, and /new-arrivals — all links present in the header/footer nav — renders 'NO PRODUCTS FOUND' / '0 Products'. Only the generic /products catalogue route returns real inventory (403 products). The backend category/menu/megamenu APIs return HTTP 200, so this is a category-to-slug/Meilisearch mapping gap, not a network failure. This breaks the CLAUDE.md bare-slug listing convention (`/<term>` should resolve as a Meilisearch category listing) for effectively every nav entry except the catch-all.
Fix: Fix the category/slug -> Meilisearch `categories` filter mapping for website-21's product catalogue so each nav category (rings, earrings, bracelets, necklaces, pendants, bestsellers, solitaire, 9kt-collection, new-arrivals) actually resolves its products. This is launch-blocking: a shopper cannot browse by category at all today.
robots.txt Sitemap directive points to https://website-21.varnijewels.com/sitemaps/website-21.varnijewels.com-sitemaps/sitemap_index.xml, which returns HTTP 404 with an S3 <Error><Code>NoSuchBucket</Code><BucketName>varnijewels</BucketName> body. Search engines following robots.txt cannot discover the sitemap at all.
Fix: Provision the sitemap-hosting S3 bucket ('varnijewels') or repoint the Sitemap: directive to wherever this store's sitemap is actually generated/hosted.
PDP page <title> ends with '| JewelWeSell' (a reference/demo brand, not Website-21). Additionally, og:site_name is 'Boris&Twins' on the home page, /products, and the PDP alike — a completely different reference brand leaking into every page's Open Graph metadata, which is what search engines and social share cards will display as the site name.
Fix: Fix the theme/SEO layer so PDP <title> suffix and og:site_name always derive from themeContent.brandName ('Website-21'), never a hardcoded/reference value.
The /products page — the one route that actually returns inventory (403 products) — has <title>Women's Fashion Online — Stylish Dresses, Co-ord Sets & More | Arialshop</title>. This is not just a brand-name leak but an entirely wrong industry vertical (women's fashion/dresses vs. lab-grown diamond jewelry) and a third distinct reference brand ('Arialshop') from the JewelWeSell/Boris&Twins ones seen elsewhere.
Fix: This route's SEO metadata is pulling from an unrelated store's config entirely. Trace the /products route's title/meta source and force it to Website-21's own themeContent, independent of whatever store record 'Arialshop' belongs to.
No Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, or Strict-Transport-Security header present on either page tested.
Fix: Add CSP, X-Frame-Options (or frame-ancestors in CSP), X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, and HSTS at the edge (Cloudflare) or app layer, fleet-wide.
No Google Analytics (gtag/GA4), Google Tag Manager, Meta/Facebook Pixel (fbq), or Microsoft Clarity script references found anywhere in the home page HTML. No dataLayer or conversion tracking of any kind detected.
Fix: Install GA4 (with Enhanced Ecommerce events: view_item, add_to_cart, begin_checkout, purchase) and/or GTM before launch; without this the store has zero visibility into traffic, conversion funnel, or ad performance.
The mobile hamburger/sidenav 'SUPPORT CONTACT' block shows [email protected] and +(973) 399-9115, which do not match this store's own identity. The footer on the same page correctly shows [email protected] and +91 90000 00000 for Website-21.
Fix: Trace the sidenav support-contact fields to their data source; they must read from themeContent (Website-21 identity) not the API store record, matching the footer's contact block.
Every page tested emits og:site_name content="Boris&Twins" regardless of the correct <title> branding elsewhere. Anyone sharing a Website-21 link on social media will see 'Boris&Twins' as the site name in the preview card.
Fix: Fix og:site_name to derive from themeContent.brandName ('Website-21'), same fix as the JSON-LD/title brand-leak findings under SEO.
See Technical SEO section for full evidence — repeated here because it is fundamentally a brand-consistency failure: three different non-Website-21 identities (JewelWeSell, Boris&Twins, Arialshop) appear across different pages of the same storefront.
Fix: Audit every page-metadata source (title suffix, og:site_name, JSON-LD org name) for hardcoded/inherited reference-brand strings and force them all to themeContent.brandName.
On the (broken, 0-product) /rings PLP, the Filter and Sort trigger buttons exist in the DOM but Playwright reports them 'not visible' / times out clicking them (they resolve to melt-ui dialog triggers with zero-size bounding boxes). Could not confirm price-range/faceted filtering or sort ordering works end-to-end.
Fix: Re-test once category PLPs return real products (current 0-product state may itself be suppressing the filter/sort UI). If still not clickable/visible once products exist, fix the trigger button's layout/visibility.
Performance 55, Accessibility 87, Best Practices 96, SEO 92. LCP 12.5s (score 0 — critical fail), FCP 8.6s (score 0), Speed Index 20.0s (score 0), TTI 12.5s, TBT 30ms, CLS 0. A shopper on mobile waits ~8.6s to see anything and ~12.5s for the main product image/content to finish loading.
Fix: Investigate PDP-specific blocking (likely large unoptimized product gallery images, render-blocking JS/CSS chunks per the large Link preload header, or slow API waterfall). This is launch-blocking for mobile conversion — most PDP visits will bounce before LCP.
Requesting the conventional /sitemap.xml path returns a JSON body '{"message":"Sitemap not found, you can generate sitemap through the admin dashboard."}' with (implied) non-XML content, instead of a valid sitemap or a proper redirect to one.
Fix: Generate the sitemap via the admin dashboard as the message instructs, or fix the S3 bucket so the robots.txt-declared sitemap resolves; either should also serve at /sitemap.xml.
Home page JSON-LD contains 'https://https://website-21.varnijewels.com/#organization' and 'https://https://website-21.varnijewels.com' (doubled protocol). PDP JSON-LD is worse: 'https://https://website-21.varnijewels.comjewelry' and 'https://https://website-21.varnijewels.comjewelry-rings' — doubled protocol AND a missing '/' between domain and path segment, producing an entirely invalid URL that no crawler/rich-result validator will resolve.
Fix: Fix the URL-concatenation helper used to build JSON-LD @id/url/breadcrumb fields — it appears to prepend a hardcoded 'https://' onto a value that already includes the protocol, and separately drops the '/' between domain and category slug on PDP breadcrumb schema.
/api/menu, /api/categories/all, /api/categories/megamenu, and /api/ms-autocomplete/products all return HTTP 200, but the category PLPs they back render 0 products — indicating a data/mapping problem (Meilisearch category field not populated for this store's product catalogue, or slug-to-category-id mismatch) rather than an outright API outage.
Fix: Dev to check the product catalogue's category-slug attribute in Meilisearch/DB for website-21 — likely not backfilled for this store's import.
The /contact-us page's extracted text contains [email protected] (reference-brand leak), [email protected] (Varni's own internal/ops domain, not a customer-facing Website-21 address), and [email protected] (an unreplaced placeholder) — plus three different phone numbers (+1 (201) 268-4531, +91 90000 00000, +(973) 399-9115).
Fix: Consolidate to a single Website-21 support email and phone number sourced from themeContent, and remove all placeholder/reference values from this page.
Same finding as Analytics & Tracking category — without GA4/GTM/pixel there is no way to measure marketing campaign performance or funnel drop-off pre-launch.
Fix: See Analytics & tracking category.
The og:site_name/title brand leaks (JewelWeSell / Boris&Twins / Arialshop) directly damage shareability and trust — any social share or SEO snippet currently promotes a different brand identity than the storefront itself.
Fix: See Brand consistency category — this is the single highest-impact fix for marketing readiness.
PDP breadcrumb 'Rings' link resolves to '/jewelry-rings' in two of three captured breadcrumb hrefs, not the canonical '/rings' used elsewhere in the site (header/footer nav, direct category link).
Fix: Standardize the ring category breadcrumb to the same canonical slug ('/rings') used by the rest of the site's navigation.
Every collection route tested (/rings, /pendants, /earrings, /bracelets, /necklaces, /bestsellers, /solitaire) shares the identical generic <title>Products</title>, with no category-specific title or meta description — a duplicate-title / thin-metadata pattern across the whole category tier.
Fix: Generate per-category titles/meta descriptions (e.g. 'Rings | Website-21 — Fine Lab Grown Diamond Jewelry') once category routing itself is fixed.
Both home and PDP HTML responses send 'access-control-allow-origin: *', an overly permissive CORS policy for full page HTML (normally unnecessary unless intentionally serving cross-origin embeds/widgets).
Fix: Confirm this is intentional (e.g. for headless/embed use cases); if not required, scope it down.
The litekart_store_id cookie is set with only Max-Age and Path — no Secure, HttpOnly, or SameSite attribute is present in the Set-Cookie header.
Fix: Add Secure; HttpOnly (if not read client-side); SameSite=Lax/Strict to the store-id cookie and audit other cookies (auth/session) for the same gap.
See Core Functionality — same finding, cross-referenced here as a frontend interaction defect (melt-ui dialog trigger elements resolve but report zero-size/hidden).
Fix: Manually verify in a real browser at desktop and mobile widths whether this is a genuine hidden-element bug or a headless-only artifact; fix if reproducible.
The <link rel="icon"> points to a store product image (frame-...jpg) rather than a dedicated favicon/logo asset, so the browser tab icon is an arbitrary product photo rather than a recognizable Website-21 mark.
Fix: Generate and wire a proper favicon (ico/png/svg) derived from the Website-21 wordmark/logo mark instead of a product photo.
Searching the rendered home page HTML for facebook.com/instagram.com/twitter.com/x.com/pinterest.com/tiktok.com links returned no matches — no discoverable social presence links for trust/marketing purposes.
Fix: Add real social profile links (not platform homepages) to the footer if Website-21 has active social accounts, or omit the section entirely rather than leaving it silently absent.
Every page navigation logs a 422 + 'Invalid credentials' console error for the wishlist fetch. Expected behavior per known fleet pattern, but it pollutes devtools and could mask real errors during debugging.
Fix: Optional: catch/silence this specific expected-401 case in the wishlist fetch handler.
Footer renders a stray line 'vvarni-storefronts' below the copyright line, reading as leftover debug/placeholder text rather than brand content.
Fix: Locate and remove/replace this stray string in the footer component/theme content.
Clicking a metal/size chip shows an unmistakable selected state: 2px solid dark maroon border (rgb(97,0,0)), matching dark text color, transparent/white background — readable and distinguishable from unselected chips.
Fix: None — meets the mandatory selected-chip contrast requirement.
Add-to-cart from PDP succeeds; cart correctly shows item, chosen variant attributes (metal/carat/ring size), subtotal, and savings; quantity/remove controls work (remove-from-cart confirmed, cart not left in a broken state); Proceed to Shipping reaches /checkout/address with contact-details form rendering. Real payment was not attempted (per audit rules).
Fix: None for this slice. Re-verify once category browsing is fixed, since most shoppers would reach a PDP via category navigation, not a direct URL.
Every page load fires a wishlist-fetch that 422s with 'Invalid credentials' for guest sessions. Per known fleet behavior this is expected (wishlist requires auth) and not a functional defect, though it does add console noise on every page.
Fix: Optional: suppress the console error for the expected guest-401/422 case to keep devtools clean, but not launch-blocking.
Performance 73, Accessibility 95, Best Practices 96, SEO 92. LCP 4.9s (poor), CLS 0 (perfect), TBT 0ms (perfect), FCP 2.9s (needs improvement), Speed Index 5.5s, TTI 4.9s.
Fix: Improve LCP (likely hero image) via preloading, next-gen format, and reduced payload.
3 JSON-LD blocks present on home (Organization/JewelryStore, WebSite, ItemList — good baseline schema coverage beyond the URL bugs above). HTTP->HTTPS redirects with 308. Canonical tag present and correct on home ('https://website-21.varnijewels.com/').
Fix: None for these specific mechanics — fix the JSON-LD URL construction bug above without removing the schema types themselves.
Site serves over HTTP/2 via Cloudflare with a valid certificate (browser/curl connect without TLS errors) and HTTP is redirected to HTTPS (308).
Fix: None.
SQL-injection protection, admin-panel hardening/MFA, password policy, session timeout, rate limiting, CAPTCHA on forms, and dependency/vulnerability scanning cannot be assessed from the outside.
Fix: Ops team should confirm: API rate limiting on auth/checkout endpoints, admin panel MFA, password complexity rules, session expiry, and a recurring dependency vulnerability scan (npm audit / Snyk / Dependabot) for the shared api.varnijewels.com backend.
Viewport meta tag is properly configured (width=device-width, initial-scale=1.0, maximum-scale=5.0 — note max-scale=5 is reasonable and doesn't block pinch-zoom). Mobile sidenav opens correctly at 390x844 and shows category shortcuts and a mini product grid.
Fix: None.
Database indexing/query performance, memory usage, background job/cron/queue health, log/exception management, cache invalidation, load balancing, and autoscaling cannot be assessed from outside the API.
Fix: Ops to confirm via internal monitoring/logs on the shared api.varnijewels.com backend.
Home accessibility 95/100 (mobile), PDP accessibility 87/100 (mobile) — both solidly in the passing range.
Fix: Address whatever Lighthouse a11y audit flagged on PDP to close the 8-point gap versus home (not itemized in this pass; re-run a11y-specific Lighthouse categories audit for the line items).
All 23 <img> tags on the home page HTML carry an alt attribute, and none were empty alt="" (which would be a red flag for meaningful product imagery).
Fix: Spot-check that alt text is descriptive (e.g. product name) rather than generic placeholder text — not verified at the text-content level in this pass.
Header, footer, and home page <title>/og:title all consistently show 'Website-21' branding with no reference-brand leak on those three specific surfaces (the leaks are elsewhere: sidenav contact, og:site_name, PDP/products titles, contact page).
Fix: Use this as the template fix pattern — extend the same theme-content-wins resolution to og:site_name, PDP title suffix, /products metadata, sidenav contact block, and the contact-us page.
Cart/checkout pages display '100% SECURE PAYMENTS', 'EASY RETURNS', 'QUALITY ASSURANCE' trust badges, and 'SECURE 256-BIT ENCRYPTION' messaging near the CTA.
Fix: None — keep, but consider adding review/rating trust signals on PDP as well (not confirmed present).
None of uptime monitoring, error tracking (Sentry-equivalent), CDN health, DB health, SSL-expiry alerts, or Core-Web-Vitals field monitoring can be confirmed from outside the site.
Fix: Ops team to confirm what's configured fleet-wide (e.g. Dokploy health checks, Cloudflare analytics, an uptime pinger, and a CWV field-data tool such as GA4/CrUX) vs. what's still needed for website-21 specifically.
Real mobile emulation (iPhone 13 (390x844, DPR3, touch on, Mobile Safari UA) via Playwright headless Chromium, Pixel 7 (412x915, DPR2.625, touch on, Chrome Mobile UA) via Playwright headless Chromium, Pixel 7 landscape spot-check (915x412)), touch interaction, thumb-driven journey.
Tapping ADD TO BAG on a PDP always fails silently. Network trace shows POST /api/carts succeeds (200) but the follow-up POST /api/carts/{cartId}/line-items always returns 400 {"message":"Variant id is required"} — regardless of whether color/cttw/ring-size chips were explicitly selected first. The cart drawer then opens showing 'EMPTY CART!! We didn't find any item inside cart.' No error toast is shown to the user; the UI gives no indication the add failed. Reproduced 3x on iPhone 13 profile (with 1 option selected, with all 3 option groups selected) and confirmed again on Pixel 7 profile — same 400 every time.
Fix: Fix the frontend variant-resolution logic so the selected option combination (color + cttw + ring size) resolves to a concrete variant id before the line-items POST fires; add a visible error toast if resolution fails. This is a full purchase-funnel blocker — nothing downstream (cart qty/subtotal, checkout address, payment) could be exercised because the cart can never contain an item.
Color chips (14K Rose Gold / White Gold / Yellow Gold), center-stone weight chips (cttw), and ring-size chips are visually IDENTICAL before and after tapping — same border (1px solid rgb(209,213,219)), same transparent background, same text color. There is no border-color change, fill, checkmark, or any other affordance to show which option is currently selected. Confirmed on both iPhone 13 and Pixel 7 profiles for color chips and ring-size chips.
Fix: Apply the standing selected-state rule for this fleet (2px primary/accent border + readable dark text on white for selected; plain gray border for unselected) to all PDP option-chip groups (color, cttw, ring size) in the lucira theme's option/variant component.
The hamburger drawer's 'SUPPORT CONTACT' section shows '[email protected]' and '+(973) 399-9115' — a different brand's ('Boris & Twins') email and phone number — instead of Website-21/Lucira contact details. Confirmed on iPhone 13 and Pixel 7.
Fix: Wire drawer support contact fields to themeContent/store settings for website-21/lucira, not a fallback/leftover value from a different tenant's data. Cross-check footer and any other surfaces (contact-us page, checkout) for the same leaked identity.
Tapping any of the 'Shop by Category' links or drawer category links (BESTSELLERS, RINGS, EARRINGS, BRACELETS, NECKLACES, PENDANTS, 9KT COLLECTION) — all of which point to bare slug routes like /rings per this fleet's link convention — lands on a page reading 'NO PRODUCTS FOUND / CLEAR ALL FILTERS', even after an 8s wait. Network trace shows the page calls /api/ms-autocomplete/products?search= with an EMPTY search term instead of passing the category slug as the filter. The full catalogue route /products works fine and returns real products, proving the product data and search API are healthy — only the slug-route category resolution is broken.
Fix: Fix the (www)/[slug] route so it passes the resolved category slug into the Meilisearch categories filter instead of an empty search term. This breaks the primary category-based navigation path for every mobile shopper who taps a category chip/menu link instead of using the full-catalogue page.
The 'Our Bestsellers' banner heading and the 'Most in Demand' banner heading render stacked directly on top of each other at mobile width — both headlines become an unreadable overlapping mess ('Our Best[Mos]t in Demand'), and their 'Explore the collection' subtext also collides.
Fix: Two adjacent full-bleed collection-banner sections are collapsing into the same layout box at mobile breakpoint (likely a missing height/margin on one card, or an absolute-positioned overlay bleeding into the next section). Give each banner card its own block height/margin at mobile widths so headings never overlap.
Rotating to landscape (915x412 on the Pixel-7-class profile) shows document.scrollWidth 1081 vs clientWidth 915 (166px of horizontal overflow) — a real user would see a slice of content cut off / scrollable sideways. The header also drops the hamburger trigger and the 'Shop by Category' row entirely, replacing them with only account/search/cart icons — an in-between state that is neither the mobile drawer pattern nor a real desktop nav (no way to reach categories at all in this state).
Fix: Add a landscape-width breakpoint that keeps the mobile hamburger nav (or a usable category-accessible nav) instead of falling into a bare desktop-icon header with no way to browse categories, and find/fix the element causing the 166px horizontal overflow.
All PDP option chips (color, cttw, ring size) measure only 36px tall (widths vary 56-135px). Ring-size chips are packed 5-per-row with narrow gaps, making them cramped for thumb tapping, especially for users with larger fingers or on a jostled commute.
Fix: Increase chip min-height to ~44px (padding or explicit min-height) across all PDP option groups.
With the drawer open, document.body computed overflow is still 'visible' (not hidden/locked) — the page behind the drawer can still scroll, which is disorienting and can cause scroll bleed-through. Separately, the drawer itself has a large empty vertical gap between the 'MY ACCOUNT' section header and the 'SUPPORT CONTACT' section — for a guest user, 'MY ACCOUNT' shows no links at all, just wasted space pushing contact info far down.
Fix: Lock body scroll while the drawer is open (overflow:hidden / scroll-trap). Either populate 'MY ACCOUNT' with guest-relevant links (Login/Register is already above it, so this section may be redundant for guests) or collapse it when empty.
The hamburger menu trigger measures ~18x18px CSS px, and the cart toggle button measures ~34x18px — both well under the ~44x44 thumb-friendly minimum, making them easy to mis-tap in a hurry.
Fix: Increase the tappable hit-area (padding) around both icons to at least 44x44 even if the visual icon glyph stays small.
Tapping the main product photo opens a full-screen zoom/lightbox overlay with a 'Close Carousel' control that spans the whole viewport (tap-anywhere-to-close). If dismissed immediately during the open transition, the first tap can fail to register; waiting ~1-1.5s (or simply tapping again) closes it reliably. Not a true trap — confirmed closeable — but the brief unresponsive window reads as a stutter/glitch to an impatient thumb user.
Fix: Low priority polish: ensure the close/backdrop tap handler is attached before or synchronously with the opening transition so the very first tap always registers.
Because Add to Cart never succeeds (see critical defect above), the cart page always shows 'YOUR BAG IS EMPTY' and /checkout/address renders only an empty-cart guard with zero form inputs. Cart quantity steppers, remove button, subtotal updates, coupon field, and the checkout address form's per-field keyboard types (email/tel/pincode) could not be exercised or verified this run.
Fix: Re-run this portion of mobile QA once the Add to Cart 400 bug is fixed.
Console repeatedly logs 'Failed to load resource: 422' and 'While fetching wishlist {message: Invalid credentials.}' for guest sessions. Per known fleet behavior this is expected for unauthenticated wishlist calls and is NOT flagged as a bug.
Fix: No action needed — documented as expected.
Desktop viewports (1920x1080, 1440x900, 1366x768), hover states, keyboard navigation, layout integrity.
header nav innerHTML is 0 chars of real content after up to 10s wait, at all 3 desktop widths. Only logo + search/account/cart icons visible in header. Root cause: /api/menu returns the 'Header' menu record with active:false and items:"" (empty string), while /api/categories/megamenu DOES return real category data (Jewelry, Rings, Earrings, etc.) that the header component is not consuming as a fallback.
Fix: Activate/populate the 'Header' menu record in store admin, or wire the header nav component to render from /api/categories/megamenu when the header menu record is inactive/empty.
All 4 tested category slug routes render an empty state despite the same categories having products under /products with a category filter applied. Reproduced at all 3 viewports.
Fix: Fix slug-route Meilisearch category filter (categories: slug) so it returns the same products /products returns when filtered by that category.
On /products, 5 of the first 6 product cards show a blank gray placeholder instead of a photo. Homepage 'Bestsellers' carousel cards are blank. PDP gallery thumbnails 4-5 are blank on the sampled product. Network shows GET https://jwsimages.s3.amazonaws.com/.../main_rg.jpg and GET https://jwsimages.s3.eu-north-1.amazonaws.com/rings/BOXIMAGE.jpg failing with net::ERR_ABORTED — these point at an unmigrated external host from the original source template instead of static.varnijewels.com.
Fix: Re-point all product/category image URLs to the migrated static.varnijewels.com CDN asset host instead of the leftover jwsimages.s3.amazonaws.com / jwsimages.s3.eu-north-1.amazonaws.com source-site references.
Every promo banner tile in the 'Shop the Collection' grid has its headline/subtext clipped by the card's left edge (e.g. 'Everyday Layers' shows as 'ryday Layers', 'Timeless Solitaires' as 'ess Solitaires'). Separately, the 'Most in Demand' section subheading renders overlapping/stacked on top of the 'Bestsellers' promo card, producing garbled overlaid text. Reproduced identically at 1920x1080, 1440x900, and 1366x768.
Fix: Fix promo-card text-block positioning (text currently bleeds outside/gets clipped by the card's overflow boundary) and fix the 'Most in Demand' heading's positioning so it no longer overlaps the adjacent Bestsellers banner card.
Hash/empty hrefs found: ["#","#","#","#","#"].
Fix: Wire real hrefs or remove anchor semantics for JS-only controls.
Grid shows 3 columns at 1920x1080, 1440x900, and 1366x768 alike; 4 columns is typical for a 1920px-wide desktop layout with a persistent filter sidebar.
Fix: Consider a 4-column breakpoint at >=1920px alongside the filter sidebar.
The three dimensions were run independently, so some findings were corrected or contradicted by a later pass. Those disagreements are recorded here rather than silently resolved — a claim below is not firm until re-verified.
Mobile QA reproduced this 3x on iPhone 13 and again on Pixel 7. Desktop QA tested a product with option chips and got 200/200 with a correct variantId. Most likely product-specific (some SKUs carry options whose id never reaches the payload) rather than a device difference.
Action: Re-verify per-product before launch; do not assume fixed.
Mobile QA found chips pixel-identical selected vs unselected on both device profiles. Desktop QA found a clear 2px maroon border on the selected chip. Suggests the selected style is present but not applied on all chip groups (colour/cttw/size) or not at mobile breakpoints.
Action: Check each option group at mobile widths specifically.