VARNI STOREFRONTS · QUALITY AUDIT · 2026-07-12
Live site: https://website-22.varnijewels.com · Design reference: limelightdiamonds.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 | 58 | warn | 5 |
| Performance | 65 | warn | 3 |
| SEO | 30 | fail | 7 |
| Security | 35 | fail | 4 |
| Frontend | 78 | pass | 3 |
| Backend (externally observable + manual) | — | manual | 2 |
| Analytics & tracking | 55 | warn | 2 |
| Accessibility | 88 | pass | 2 |
| Brand consistency | 18 | fail | 6 |
| Marketing readiness | 28 | fail | 4 |
| Monitoring & maintenance | — | manual | 1 |
39 findings across functionality, SEO, security, performance, accessibility, analytics and brand consistency.
<title> on https://website-22.varnijewels.com/products is 'Women's Fashion Online — Stylish Dresses, Co-ord Sets & More | Arialshop' and the meta description reads 'Explore Arialshop's exclusive collection of women's fashion...Refresh your wardrobe with Arialshop today!'. This is the single most severe defect found: anyone sharing, indexing, or clicking through to the store's main catalogue page in search results or social previews sees an unrelated fashion brand, not this jewelry store.
Fix: LAUNCH BLOCKER. This looks like shared/cross-tenant page-metadata bleeding from a different fleet store's page config into this store's /products route (backend page CMS or cache key collision). Fix the page-metadata resolution so /products always pulls website-22's own title/description; purge any shared cache keyed only by route path.
robots.txt correctly references Sitemap: https://website-22.varnijewels.com/sitemaps/website-22.varnijewels.com-sitemaps/sitemap_index.xml, but fetching it returns an XML S3 error: <Error><Code>NoSuchBucket</Code><Message>The specified bucket does not exist</Message><BucketName>varnijewels</BucketName></Error>. No sitemap is discoverable for this store at all.
Fix: LAUNCH BLOCKER for indexability. Fix the sitemap generation/hosting pipeline (wrong bucket name/region) so a valid sitemap_index.xml is served; resubmit in Search Console once fixed.
The mobile-nav drawer's 'SUPPORT CONTACT' block and the homepage nav both link mailto:[email protected] and tel:+(646) 598-7516. The Organization JSON-LD schema repeats the same phone/email plus a real-looking US street address ('340 Amboy Ave, Metuchen, NJ') and JewelWeSell's real social handles (x.com/JewelWeSell, facebook.com/@JewelWeSell1, instagram.com/jewelwesell, youtube.com/user/JewelWeSell, pinterest.com/jewelwesell). Meanwhile the footer shows a THIRD, unrelated, and clearly fake contact set: 'Bandra Kurla Complex, Mumbai, Maharashtra 400051', phone '+91 90000 00000' (placeholder all-zeros number), email '[email protected]' (.example is an IANA reserved non-functional domain). A real customer calling/emailing the number/address shown in the header would reach a different company (JewelWeSell), not this store.
Fix: LAUNCH BLOCKER. Remove every reference to the JewelWeSell reference brand's real phone/email/address/social handles from theme content and structured data; replace the footer's placeholder Mumbai address/fake phone/.example email with this store's real, working contact details before launch. Reconcile to a single consistent contact identity across header, footer, and JSON-LD.
Duplicated here because it is as much a brand-consistency failure as an SEO one: the store's main catalogue page literally presents itself as 'Arialshop' in its <title> and meta description, a women's-fashion competitor brand, not Website-22 or even JewelWeSell.
Fix: Same fix as the SEO finding — this is the single highest-priority item in the whole audit.
sameAs in the Organization schema lists x.com/JewelWeSell, facebook.com/@JewelWeSell1, instagram.com/jewelwesell, youtube.com/user/JewelWeSell, pinterest.com/jewelwesell — all real accounts for a different company, not 'Website-22'. This fails the 'real social profile links (not platform homepages)' requirement in the worst possible way: they're real, but for someone else's brand.
Fix: Replace with this store's own social accounts, or omit sameAs until real accounts exist — never point at a different real business's profiles.
Footer 'About' links (/pages/about-us, /pages/sustainable-diamond), footer 'Policies' links (/p/terms, /p/return-policy), and footer category shortcuts (/categories/rings, /categories/earrings, /categories/pendants, /categories/bracelets, /categories/solitaire) all 404. Working equivalents exist at different paths (/about-us, /faqs, /p/privacy-policy, /rings, /earrings...), so these are stale/duplicate footer hrefs pointing at routes that were never wired.
Fix: Point footer 'About' and 'Policies' columns at the working routes (/about-us, /faqs, /p/privacy-policy style paths) or add redirects; fix the footer category-column hrefs to the working bare-slug routes (/rings, /earrings, etc.).
curl of https://website-22.varnijewels.com/products (no JS) contains 0 `href="/products/..."` links and no filter/sort/facet class names anywhere in the 400KB response. Products and filters only appear after client-side hydration (confirmed 5-6 products render via headless Chrome with JS). No sort control or filter UI was found even after hydration in this Playwright pass.
Fix: Confirm PLP actually renders a working filter/sort UI (re-verify with a longer wait / different selectors); if genuinely absent, this blocks the PLP filter/sort/pagination requirement of the audit checklist entirely.
Sampled one earrings PDP and one ring PDP (both screenshotted). Neither exposes clickable metal/size option chips; the only interactive selector is a 'Complimentary Engraving (optional)' dropdown. Each size/metal instead appears to be modeled as a fully separate product URL (e.g. ring slug literally embeds '_-sz0875' in the URL), and FAQ copy on the PDP itself asks 'Can I customize the metal or size?' implying variant switching was expected but is not present as in-page UI.
Fix: If this catalog intentionally sells each size/metal as a distinct SKU/URL rather than swatches, the PDP copy referencing 'customize the metal or size' is misleading and should be corrected, or a real in-page selector should be built so the mandatory selected-state check (2px accent border / readable dark text on white bg) can be verified. Re-test on a product proven to carry Litekart `variants` before concluding this is fleet-wide.
Lighthouse (mobile default throttling, headless): Performance 62/100. LCP 6.7s (poor, threshold <2.5s good/<4s needs-improvement), FCP 3.3s (poor), Speed Index 9.3s (poor), TBT 0ms (good), CLS 0.031 (good).
Fix: Investigate render-blocking CSS chain (many per-route stylesheet chunks preloaded via Link header), reduce unused JS (~92 KiB) and unused CSS (~25 KiB) per Lighthouse, and shorten server response time (root document TTFB measured at 1,660 ms).
Organization/JewelryStore JSON-LD on the homepage has "@id":"https://https://website-22.varnijewels.com/#organization" and "url":"https://https://website-22.varnijewels.com" (double 'https://'), which will fail strict schema validators. The same block's name is 'Website-22' but contactPoint/address/sameAs are all real JewelWeSell reference-brand data (see Brand consistency section for detail).
Fix: Fix the URL template that's prefixing an already-absolute URL with an extra 'https://'; run the block through Google's Rich Results Test after fixing.
curl -I on the homepage, a PDP, and /checkout/address show no Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, or Strict-Transport-Security headers on any of them.
Fix: Add CSP, X-Frame-Options (or frame-ancestors in CSP), X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, and HSTS at the CDN/edge or app-server layer for the whole fleet (likely a shared Dokploy/Cloudflare config change, not per-store).
<title>Cart - Jewelwesell</title> and <title>Address - Jewelwesell</title> on the two checkout steps tested, while the visible header/stepper/footer on those same pages correctly render 'WEBSITE-22'. This is a partial regression of the wordmark-parity fix: the visible DOM wordmark correctly resolves themeContent.brandName || storeData?.name, but the <svelte:head> title template for at least /checkout/cart and /checkout/address still falls back to the raw API store name.
Fix: Audit every route's page-title template fleet-wide for the same storeData?.name-wins-over-themeContent.brandName bug already fixed for the header/sidenav; checkout appears to be an exception that still needs the flip.
Phone '+91 90000 00000' is an obviously-fake all-zeros placeholder number; email '[email protected]' uses the .example TLD reserved by IANA for documentation and cannot receive mail; the Mumbai 'Bandra Kurla Complex' address has no suite/building identifier and may not be a real, staffed location for this brand.
Fix: LAUNCH BLOCKER for trust/marketing readiness. Replace with a real, monitored support email/phone/address before go-live — a customer who calls or emails this will get nothing.
Lighthouse on a sample PDP: Performance 74/100. LCP 3.9s, FCP 3.3s, Speed Index 8.5s, TBT 10ms, CLS 0.007.
Fix: Same remediation as homepage — prioritize LCP image/element preload and reduce main-bundle JS.
Root document took 1,660 ms to respond on the homepage. Lighthouse also flags render-blocking resources, unused JS/CSS, missing modern image formats and missing responsive images as improvement opportunities (all scored 0/1 as 'opportunity' audits, not hard failures).
Fix: Enable/verify server-side caching for the SvelteKit SSR route, ship WebP/AVIF for hero and category SVGs where raster equivalents exist, and split/tree-shake unused JS bundles.
Homepage <meta property="og:site_name" content="Jewelwesell"/> and the WebSite JSON-LD block's "name":"Jewelwesell" both use the backend store-account name instead of the theme's 'Website-22' brand — same PDP page also carries og:site_name=Jewelwesell. <title> and visible copy correctly say Website-22, so this is specifically an SEO/social-metadata layer that still derives brand from the API account rather than themeContent.
Fix: Wire og:site_name and the WebSite/Organization JSON-LD 'name' fields to themeContent.brandName the same way <title> already correctly does.
og:image and twitter:image both point to "/limelight/hero-1.svg" — a relative path (should be an absolute URL for social crawlers) and an SVG (Facebook/Twitter/LinkedIn previews frequently fail to render SVG og:image).
Fix: Serve an absolute https:// URL to a PNG/JPG (1200x630) for og:image/twitter:image.
Set-Cookie: litekart_store_id=store_01JNKD4PGSR8E3QZSGXYEE0PRV; Max-Age=31536000; Path=/ — no Secure, HttpOnly, or SameSite flags present in the header.
Fix: Add Secure; HttpOnly (where the cookie doesn't need JS access); SameSite=Lax/Strict to the cookie-setting logic.
Both audited pages fail the 'color-contrast' binary audit (background/foreground contrast insufficient somewhere on the page) and the homepage fails 'heading-order' (headings not in sequentially-descending order). Homepage also flags 'image-redundant-alt' (alt text duplicates adjacent visible text).
Fix: Run axe/Lighthouse's element list for color-contrast to find the exact low-contrast text/background pairs (likely the muted assistance/footer copy on the plum background); fix heading hierarchy (h1→h2→h3 without skipping).
Lighthouse's server-response-time audit measured the root document taking 1,660 ms to respond, which eats into the LCP/FCP budget seen above.
Fix: Profile SSR route (SvelteKit + API round-trip to api.varnijewels.com) for this store; consider edge caching of the homepage HTML shell.
gtag.js loads with measurement ID G-LXBXGL3R0P and window.dataLayer is initialized; a page_view collect request fires on every page navigated to in this audit (home, /products, PDP, cart, checkout/address) — each showed the correct dl/dt values matching the page. However, every one of these GA collect requests was captured with net::ERR_ABORTED in the network log, and no add_to_cart/begin_checkout event was inspected in the dataLayer during the Add-to-Bag click performed in this audit.
Fix: Confirm whether the ERR_ABORTED collect requests are a headless-browser/navigation-timing artifact of this audit (page closing before the beacon completes) or a real issue (e.g. an ad-blocker rule, or the app navigating away too fast for sendBeacon/keepalive to complete) using a real browser session. Separately, verify add_to_cart/view_item/begin_checkout events are actually pushed to dataLayer via GTM Preview mode.
No cookie-consent banner or Google Consent Mode signal was seen on first load in any of the pages visited, despite EU-style analytics/consent parameters (gcd=13l3l3l3l1l1, npa=0/1, dma=0) appearing in the GA payloads.
Fix: If this store serves EU/UK/India traffic requiring consent, add a consent banner and wire real Consent Mode state instead of static defaults.
color-contrast fails on both pages; heading-order fails on home; image-redundant-alt fails on home (alt text duplicating visible caption text on some images).
Fix: Fix the specific low-contrast text/background combination(s) and normalize heading levels; trim redundant alt text where an adjacent caption already states the same text.
The footer renders a literal line of text 'vvarni-storefronts' below the copyright line on every page (home, cart, checkout/address, PDP).
Fix: Remove or hide this internal version/debug string from the public-facing footer; if it's useful for ops, put it behind a query param, admin view, or HTML comment instead of visible body text.
Unlike the mandatory-check failure pattern this audit specifically looks for, the visible brand name in the header logo, the opened mobile hamburger drawer's top wordmark, the footer brand link, and the copyright line all correctly read 'WEBSITE-22' / 'Website-22' — no 'Boris & Twins'-style raw API account name leak was found in the nav chrome itself. This mandatory check PASSES; the failures above are in metadata layers (page <title>, structured data, og:site_name, contact links), not the visible nav wordmark.
Fix: None for the nav wordmark itself — but see the checkout <title> and structured-data findings above for where brand parity still leaks.
Duplicated from SEO — directly affects how the store's link preview looks when shared on WhatsApp/Facebook/X/iMessage.
Fix: Ship an absolute-URL 1200x630 PNG/JPG og:image.
Static HTML shows 'No products available — Products will appear here when they are returned by the API' in the Most in Demand section; after client hydration the section does populate with 6 products with prices. Non-blocking for real users but means crawlers/no-JS clients and the first paint see an empty state.
Fix: Consider SSR-ing the featured product list (or at least the first page) so it isn't empty pre-hydration.
Lighthouse's robots-txt audit failed with 'Lighthouse was unable to download a robots.txt file', while a plain curl from this environment retrieved a full, syntactically normal robots.txt (with sitemap directive, per-bot rules, adsbot-google notes). Could be a Cloudflare bot-challenge triggered specifically by the Lighthouse/headless UA, or a flake.
Fix: Re-check with a real Googlebot UA / Search Console 'robots.txt tester' to rule out a Cloudflare rule blocking crawler UAs specifically.
Both viewports rendered cleanly in Playwright with no visible overflow; mobile hamburger menu opens a full sidenav drawer correctly with 'Close sidebar' control.
Fix: None.
Homepage 'Our Story' section: 'Founded in 2019, Website-22 Lab Grown Diamonds has become India's largest lab grown diamond jewellery brand, with stores across 45+ cities' and footer address is a Mumbai landmark, yet every price shown (home, PLP, PDP, cart) uses a '$' prefix (e.g. $1871.00) and the PDP Product Specifications table lists Origin: 'United States of America'.
Fix: Decide the store's actual target market and make copy/currency/origin consistent — either India-facing with ₹ pricing, or reword the 'India's largest' story copy if this is actually a US-facing store.
Full flow verified end-to-end in headless Playwright: PDP 'Add to bag' → cart shows item, qty 1, correct subtotal ($1871.00), discount line, promo-code field, 'Proceed to Shipping' → /checkout/address renders a guest contact form (email + optional phone), progress stepper (1 Cart / 2 Address / 3 Payment), price summary carried over, 'Select Address' CTA. No console errors besides the expected guest-wishlist 422.
Fix: None — this part of the flow is solid. Stopped before entering payment/personal data per audit rules.
Sampled PDP carries Product, Offer, AggregateRating, Brand and BreadcrumbList JSON-LD, canonical tag correctly self-referential, and Lighthouse SEO score is 100/100 on that page.
Fix: None — keep this pattern; just fix the /products page metadata bug above.
Certificate for varnijewels.com issued by Google Trust Services (WE1), valid May 30 2026–Aug 28 2026, no mixed content observed, HTTP/2 in use.
Fix: None — monitor renewal (expires Aug 28 2026, well ahead of today).
Not observable from outside the app; these live in the shared api.varnijewels.com backend and Dokploy infra.
Fix: Ops team should verify: WAF/rate-limit rules at Cloudflare, backend CSRF/XSS middleware, admin panel auth (MFA), password policy, session expiry, and run a vuln scan against api.varnijewels.com.
Only console errors captured across the whole journey were the expected guest-wishlist 422/'Invalid credentials' pattern, which is documented as expected (not a bug) per the fleet's known-fix list.
Fix: None.
Not observable from outside; these live in the shared Litekart/api.varnijewels.com backend and Dokploy infra shared across the fleet.
Fix: Ops team to check backend APM/logs, queue dashboards, DB slow-query log, and autoscaling policy for api.varnijewels.com.
Homepage images (category tiles, trust-badge SVGs, hero image) all carry non-empty, descriptive alt attributes (e.g. alt="Rings", alt="Assurance point 1", alt="Website-22 lab grown diamond jewellery campaign").
Fix: None — keep this pattern; note the generic 'Assurance point 1..6' alt text is low-information and could be more descriptive of what each trust badge actually claims.
PDP shows 'Certified Quality (IGI/SGL)', 'Secure Setting', 'Lifetime Exchange', 'Insured Shipping' badges, a 7-step 'Our Process' manufacturing story, warranty/return-policy accordion, and an honest 'No reviews yet' empty state rather than fake reviews.
Fix: None — this is good practice; keep it once the identity/contact issues above are fixed.
This audit can only confirm the SSL certificate's current validity window (valid through Aug 28 2026) and the lab (synthetic) Lighthouse scores captured above; it cannot confirm whether any uptime/error/CWV field-monitoring, automated SSL-renewal, or backup-verification is configured for this store.
Fix: Ops team should confirm: uptime monitor (e.g. UptimeRobot/Pingdom) pointed at website-22.varnijewels.com, CrUX/field CWV monitoring enabled, SSL auto-renewal configured well ahead of Aug 28 2026 expiry, and a broken-link crawl scheduled given the 9 broken footer links already found by this one-time audit.
Real mobile emulation (iPhone 13 (390x844, DPR3, touch, Mobile Safari UA), Pixel 7 (412x915, DPR2.625, touch, Chrome Mobile UA), Landscape spot-check on home (both profiles, rotated)), touch interaction, thumb-driven journey.
document.title on https://website-22.varnijewels.com/checkout/cart is 'Cart - Jewelwesell'. Jewelwesell is a different jewelry brand/source theme, not Website-22. This is visible in the browser tab, in any shared/bookmarked link preview, and in analytics payloads (confirmed via GA4 collect request dt= parameter and a direct page.title() check). A shopper glancing at their tabs while paying would see the wrong company name at the single most trust-sensitive step of the journey.
Fix: Audit all route-level <title>/meta tags for hardcoded or mis-sourced brand strings; every checkout-flow page title must derive from the active theme's brandName, not a leftover source-theme string.
document.title on https://website-22.varnijewels.com/products is "Women's Fashion Online — Stylish Dresses, Co-ord Sets & More | Arialshop". Website-22 sells lab-grown diamond jewelry; this title is for a different store, different brand name, and a different product vertical (women's fashion/dresses) entirely. Confirmed reproducible on repeat page.title() checks.
Fix: Same root cause as the checkout title leak - fix the PLP route's title/meta generation to use the active theme's brand + jewelry-appropriate copy per the diamond-jewelry-content standing rule.
The primary gallery image request to https://media.jewelwesell.com/cdn-cgi/image/width=1280,quality=80,format=auto/stores/store_01JNKD4PGSR8E3QZSGXYEE0PRV/product/20260519/400-ct-ef-vs-lab-grown-diamond-cartoon-pendant-in-14k-white-gold-232635-0.jpg fails with net::ERR_BLOCKED_BY_ORB (Chromium's Opaque Response Blocking) on every repeat load, on both iPhone 13 and Pixel 7 profiles, and under throttling. Result: the product photo area is a flat light-grey placeholder with no image, icon, or retry affordance - on the exact page where a shopper is deciding whether to buy. The image host itself is 'media.jewelwesell.com', again leaking the wrong brand's domain into production asset URLs. ORB is a standard, always-on Chromium/mobile-Chrome protection (and Safari has an equivalent), so this is expected to affect real customers on real phones, not just this test tool.
Fix: Fix the image CDN response so it isn't cross-origin-opaque (correct Content-Type + CORS headers, or serve from the store's own asset domain instead of media.jewelwesell.com). Also treat this as another brand-domain leak to remove from asset URLs.
Measured bounding box of the header hamburger button on both iPhone 13 and Pixel 7 profiles: 18x18 CSS px. This is the primary nav trigger tapped on nearly every mobile session.
Fix: Increase the button's own hit area (padding, not just icon size) to at least 44x44px.
Opening the hamburger drawer shows a SUPPORT CONTACT block with [email protected] and +(646) 598-7516 - a different real business, not Website-22. Confirmed present via body text extraction during this pass; carried over from the prior launch-readiness finding, still unresolved.
Fix: Replace with Website-22's own support email/phone or a clearly different placeholder, per the theme identity-replacement rule.
Cart line-item quantity buttons measured 28x28px; the remove (trash) icon measured 30x30px, on both iPhone 13 and Pixel 7. Both sit inside a bordered wrapper with some surrounding whitespace, so they are usable but cramped for a thumb, especially the trash icon which is a destructive action.
Fix: Pad both controls to a minimum 44x44px hit area.
Timed pass: DOMContentLoaded at 10.4s, Add to Bag first became tappable at the same ~10.4s mark. For the entire wait, the product photo area shows a flat grey box with zero loading indication (no shimmer, spinner, or skeleton), which can read as frozen/broken to an impatient thumb user on a real slow connection - especially since the jewelry photo is the primary trust/decision asset.
Fix: Add a skeleton/shimmer state for the product image and consider serving a smaller first-paint image variant for slow connections.
The tested product ('Cartoon Pendant') has only one gallery image (one pagination dot), so a genuine swipe-between-images gesture could not be exercised. A mouse-drag across the image was interpreted as a tap and opened a fullscreen zoom overlay with a small top-right close (X) - functional and closable, but this specific product could not confirm true swipe-carousel paging.
Fix: Manually re-check swipe/pinch-zoom behavior on a PDP with multiple gallery images; not able to fully verify with this specific single-image product.
On iPhone 13, cart/added confirmation text was detected in the page body shortly after tapping Add to Bag. On Pixel 7, no confirmation text was detected in the same window, though the screenshot shows the button visibly change to a lighter/muted color with a loading-shimmer pattern immediately after tap, suggesting an in-flight async state rather than a missing feature. Not confirmed as a true defect - may just need a longer wait before checking for a toast/cart badge count.
Fix: Manually confirm a toast and/or cart-icon badge count reliably appears within ~2-3s of tapping Add to Bag on all profiles.
A correctly labelled, full-width, 64px-tall, thumb-reachable sticky 'ADD TO BAG' button is present and functional on both iPhone 13 and Pixel 7 profiles, and successfully adds the item to cart. Root cause of the earlier false read: the DOM contains a second, hidden duplicate 'Add to bag' button earlier in document order (likely a responsive variant hidden via CSS at mobile widths); a test that only checks the first DOM match for that text can wrongly conclude the button is absent. Recommend cleaning up the redundant hidden markup for hygiene, but this is not a customer-facing defect.
A 'Sort By' and 'Filter' control bar is fixed at the bottom of the PLP product grid and is visible on both iPhone 13 and Pixel 7 at /products. Not independently re-verified that tapping Filter opens a fully working sheet with functioning apply behavior (out of scope for this pass to avoid re-deriving), but the controls are present and visible, contradicting the earlier launch-readiness note.
Desktop viewports (1920x1080, 1440x900, 1366x768), hover states, keyboard navigation, layout integrity.
nav.limelight-nav renders 0 children at every desktop width. Only the logo and 4 action icons (search, wishlist, account, cart) appear in the header. Root cause confirmed via API: GET /api/menu returns the 'Header' menu record ({menuId:'header'}) with active:false, so the theme's nav component has nothing to render. A separate endpoint, /api/categories/megamenu, DOES return live category data but the header doesn't appear to consume it.
Fix: Activate the 'Header' menu CMS record, or point the theme's nav render at /api/categories/megamenu which already returns working category data.
PDP hero image shows a full diagonal repeating 'JewelWeSell' script watermark plus a diamond+'W' logo mark across the entire background. The same watermark is faintly tiled behind every PLP thumbnail. Source images are served via media.jewelwesell.com / static.varnijewels.com with the mark burned in -- not something CSS/theme code can fix.
Fix: Re-source or reprocess (crop/clean) product photography before serving it on a Website-22-branded storefront; this is an asset-pipeline / content problem, not a theme code fix.
Dead links: /categories/rings, /categories/earrings, /categories/pendants, /categories/bracelets, /categories/solitaire, /pages/about-us, /pages/sustainable-diamond, /p/terms, /p/return-policy, /p/exchange-buyback. Working: /p/privacy-policy, /p/shipping-policy, /store-locator, /contact, /products, /.
Fix: Point footer category links at this app's canonical bare-slug routes (e.g. /rings, /earrings) per the repo's own link convention instead of /categories/<slug>; fix or remove the /pages/* and dangling /p/* static page links.
/products title = 'Women's Fashion Online — Stylish Dresses, Co-ord Sets & More | Arialshop' (a fashion brand, not Website-22/diamonds); /checkout/cart title = 'Cart - Jewelwesell'; /checkout/address title = 'Address - Jewelwesell'. Identical at all 3 desktop widths.
Fix: Set correct per-route <title> using the theme's brand config instead of the leaked/hardcoded source titles.
Clicking a left-rail category (e.g. 'Charms Cluster Pendants') from /products correctly SPA-navigates to /charms-cluster-pendants (breadcrumb and '64 Products' count update correctly), but every product image on the resulting grid stays a blank grey box even after 3+ seconds. Reloading the exact same URL directly (full page load) renders all images correctly (naturalWidth 1280, complete:true).
Fix: Re-trigger image src/lazy-load on client-side route change; the image/lazy-load component likely isn't re-mounting or re-observing intersection after an SPA navigation.
On the sampled product PDP, the 'SIZE & CUSTOMIZATION' section header renders but the container below it is empty (3 empty Svelte comment placeholders, no metal/size/carat chips), so there is no visible way to configure the piece before Add to Bag despite the heading implying configurability.
Fix: Confirm whether this SKU legitimately has no variant options (then hide the empty section) or whether the variant/option fetch is silently failing (then fix data binding).
Cursor shows a zoom-in affordance on hover over the main image, but nothing actually magnifies in place; the only zoom interaction is a click-to-open carousel/lightbox (Previous/Next/Close Carousel controls).
Fix: If hover-zoom is intended, wire an actual magnifier/lens on mousemove; otherwise the cursor affordance should match actual (click-to-view) behavior.
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 saw net::ERR_BLOCKED_BY_ORB and a blank grey box on both device profiles and under throttle. Desktop QA in real Chromium found the image loads fine at 2076x2076. The cross-origin media.jewelwesell.com hotlink is real either way; the block appears device/context dependent.
Action: Treat the hotlink itself as the defect — it is both the brand leak and the fragility. Serve imagery from static.varnijewels.com.
Both QA passes found a working filter sidebar and sort dropdown. The original finding matched only the mobile-only bottom bar (md:hidden) being absent from the server-rendered HTML.
Action: None — not a defect.