VARNI STOREFRONTS · QUALITY AUDIT · 2026-07-12
Live site: https://website-19.varnijewels.com · Design reference: target.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 | 40 | fail | 6 |
| Performance / Core Web Vitals | 50 | fail | 3 |
| SEO (technical) | 35 | fail | 9 |
| Security | 35 | fail | 4 |
| Frontend / Responsive | 68 | warn | 3 |
| Backend (externally observable + MANUAL) | — | manual | 2 |
| Analytics & Tracking | 55 | warn | 3 |
| Accessibility (WCAG) | 82 | warn | 5 |
| Brand Consistency | 15 | fail | 3 |
| Marketing Readiness | 50 | warn | 3 |
| Monitoring & Maintenance | — | manual | 1 |
Lighthouse CLI, mobile emulation defaults.
| Page | performance | accessibility | best_practices | seo | lcp | fcp | cls | tbt | speed_index | interactive | url |
|---|---|---|---|---|---|---|---|---|---|---|---|
| home_mobile | 0.56 | 0.98 | 0.96 | 1 | 8.3 s | 6.3 s | 0.022 | 10 ms | 17.3 s | 9.8 s | — |
| pdp_mobile | 0.55 | 0.88 | 0.96 | 0.92 | 8.6 s | 6.9 s | 0.001 | 20 ms | 14.0 s | 9.7 s | https://website-19.varnijewels.com/products/400-ct-ef-vs-lab-grown-diamond-cartoon-pendant-in-14k-white-gold-232635 |
42 findings across functionality, SEO, security, performance, accessibility, analytics and brand consistency.
The header/megamenu links 'Engagement Rings' and 'Wedding Bands' both point to /jewelry-rings; 'Diamonds', 'Necklaces', 'Earrings', 'Bracelets' all point to /jewelry. Both slug routes return 'NO PRODUCTS FOUND / 0 results' even in raw SSR HTML (verified via curl, not just client hydration lag). Only 'Categories' and 'Bestsellers' (both -> /products, the full catalogue) actually list products. Per the project's Meilisearch categories:slug convention, this means no product in the catalogue is tagged with a 'jewelry-rings' or 'jewelry' category slug, so 6 of 8 primary nav destinations are dead ends for shoppers.
Fix: Wire the megamenu to the store's real backend category taxonomy/slugs (per the project's 'megamenu from backend API' rule) instead of hardcoded /jewelry-rings and /jewelry, or re-tag products so those slugs return results.
Lighthouse mobile: Home LCP 8.3s / FCP 6.3s / Speed Index 17.3s. PDP LCP 8.6s / FCP 6.9s / Speed Index 14.0s. Google's 'Good' threshold is LCP < 2.5s and FCP < 1.8s; both pages are more than 3x over the Good LCP threshold and squarely in the 'Poor' bucket.
Fix: Investigate render-blocking JS/CSS (site preloads ~100 modulepreload chunks on first response — see Link header), defer non-critical chunks, and confirm the LCP element (hero image / PDP gallery image) is prioritized (fetchpriority=high, preloaded, correctly sized).
robots.txt declares 'Sitemap: https://website-19.varnijewels.com/sitemaps/website-19.varnijewels.com-sitemaps/sitemap_index.xml'. Fetching that URL returns an XML S3 error 'NoSuchBucket / BucketName: varnijewels' on one request and a plain 404 on a retry. /sitemap.xml at the site root also returns empty content. Search engines cannot discover the site's URL list.
Fix: Fix the sitemap generation/storage pipeline (S3 bucket reference is wrong or missing) and confirm sitemap_index.xml + child sitemaps resolve with 200 and valid XML before launch.
Homepage Organization/JewelryStore JSON-LD correctly uses name 'Website-19', but the sibling WebSite JSON-LD block on the same page has name:'Jewelwesell' and description:'<p></p>' (empty placeholder). The Organization block's own '@id' and 'url' fields are malformed with a doubled protocol: 'https://https://website-19.varnijewels.com/#organization' and 'https://https://website-19.varnijewels.com' — these will fail schema validation / Rich Results eligibility. The Organization contactPoint email is '[email protected]', not a Website-19 address.
Fix: Fix the double-https URL bug in the Organization schema generator, replace 'Jewelwesell' with the theme's brandName in the WebSite schema, and replace the leaked support email/phone with the actual Website-19 contact details.
Homepage title/OG correctly say 'Website-19 — Certified Diamonds & Fine Jewelry', but og:site_name is 'Jewelwesell' even on the homepage, and every other page's <title>, og:title, og:description, twitter:title, twitter:description read 'Jewelwesell' instead of Website-19: /products -> 'Shop All Products | Jewelwesell' (+ og:description 'Explore our latest collection at Jewelwesell...'), /checkout/cart -> 'Cart - Jewelwesell', /checkout/address -> 'Address - Jewelwesell', PDP -> '... 232635 | Jewelwesell'.
Fix: This is the single largest brand-consistency defect on the site (see Brand Consistency category) and a genuine copyright/reference-brand-name leak per project rules. Every page-level title/meta template must read the theme's brandName, not a hardcoded 'Jewelwesell' fallback.
While the header wordmark, the mobile sidenav, the footer, the homepage <title>, and the homepage Organization JSON-LD all correctly show 'Website-19', a large and systemic set of surfaces still read 'Jewelwesell' (the apparent reference/competitor site this theme was cloned from): og:site_name on every page including the homepage; <title>/og:title/og:description/twitter:title/twitter:description on /products, /checkout/cart, /checkout/address, and PDP pages; the WebSite JSON-LD 'name' field; and the Organization JSON-LD contactPoint email '[email protected]'.
Fix: This is the top-priority fix before launch: audit every title/meta/schema template for a hardcoded 'Jewelwesell' fallback or literal string and replace with themeContent.brandName ('Website-19'), and replace the support email/phone with the real Website-19 contact details.
The PDP product image (a diamond pendant) has a faint but clearly visible cursive 'JewelWeSell' watermark and a stylized 'W' logo baked into the photo itself.
Fix: Do not use reference-site product photography with its watermark intact — this is both a brand-consistency failure and a real copyright/plagiarism risk per the project's originality rules. Source clean/licensed product imagery or have the watermark removed before these images are used in a live store.
During the walkthrough, console repeatedly logged 'Error fetching menu: {message: Please check your internet connection and try again}' and 'Search error: {message: ...}' even though the network was fine and the page rendered content. Suggests a flaky API call or a race condition on the menu/search fetch (possibly a timeout too short, or the fetch firing before the store/session is ready).
Fix: Investigate the menu/search API client's timeout and retry behavior; confirm it isn't erroring on cold start or on first paint before session/store id is set.
/jewelry-rings and /jewelry both return HTTP 200 with zero results, and both were observed with the generic title 'Products' rather than a unique, descriptive category title. A 200-status empty results page is a soft-404 SEO anti-pattern, and duplicate/generic titles across distinct category URLs hurt search differentiation.
Fix: Once the category/slug wiring is fixed (see Core Functionality), also give each category page a unique <title>/meta description, and consider returning a real 404 or noindex for genuinely empty category states.
Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and Strict-Transport-Security (HSTS) were all absent from response headers on /, PDP, /checkout/cart and /checkout/address.
Fix: Add the standard security header set at the CDN/edge (Cloudflare) or app layer: CSP (at least a reasonable default-src), X-Frame-Options: DENY/SAMEORIGIN, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, and Strict-Transport-Security with a sensible max-age.
Unlike prior findings on other stores in this fleet, the header logo, the mobile hamburger/sidenav, and the footer here ALL correctly show 'Website-19' — no API store-account-name leak (e.g. no 'Boris & Twins'-style leak) was found in the primary navigation surfaces.
Fix: Keep this working correctly; the remaining brand-consistency work is entirely in page-level metadata/schema/imagery, not in-app navigation chrome.
A visible 'Search for rings, diamonds, gifts…' box renders in the header, but standard input selectors did not find a real <input> element in two automated passes, and typing did not consistently produce a results dropdown in the automated run.
Fix: Manually re-verify search-as-you-type suggestions and full search-results page in a real browser; confirm results respect the project's bare-slug link convention rather than /products?search=.
The PDP variant/selected-state check could not be exercised: the pendant PDP and the engagement-ring PDP both have zero metal/size swatches. Product titles instead bake the size directly into the product name/slug (e.g. '..._Sz0875-102848'), implying each size is modeled as a separate product/SKU rather than a variant of one PDP.
Fix: Not a selected-state visibility bug (there is no selector to fail), but this materially hurts comparison shopping (customers must browse separate listings per size) and inflates catalogue/SEO duplication. Consider a true variant picker if the backend supports grouping by base product.
Home performance category score 0.56, PDP 0.55.
Fix: Target 90+ before launch for an ecommerce storefront; current scores indicate real-world mobile shoppers will perceive the site as slow to first paint.
og:image and twitter:image are empty strings ('') on /products, meaning link shares of the catalogue page will render with no preview image.
Fix: Set a fallback OG image for listing pages when no category-specific image exists.
The WebSite schema's potentialAction.target.urlTemplate is 'https://website-19.varnijewels.com/products?search={search_term_string}'. Per the project's standing link-convention rule, term/category search should resolve via the bare slug route (e.g. /{search_term_string}), not a query-string search on /products.
Fix: Point the SearchAction template at the bare-slug pattern (e.g. https://website-19.varnijewels.com/{search_term_string}) to match every other generated link on the site.
PDP 'Description' section literally renders '-' and 'Specifications' has no visible content; this is thin content that will not help topical relevance or user trust.
Fix: Populate real product descriptions/specs per SKU or hide empty sections instead of rendering a bare dash.
The store-id cookie is issued with only Max-Age and Path; no Secure, HttpOnly, or explicit SameSite attribute is visible in the raw Set-Cookie header, though the browser-level cookie jar reported SameSite=Lax by default.
Fix: Mark non-essential/tracking-adjacent cookies Secure (site is HTTPS-only) and HttpOnly where the cookie is not read by client JS; confirm SameSite is explicit rather than relying on browser defaults.
Across Home -> PLP -> PDP -> Cart -> Checkout-address, 38 console.error entries were logged. Most are the expected guest-wishlist 422, but a meaningful subset are 'Error fetching menu' / 'Search error: Please check your internet connection and try again' style failures that do not correspond to an actual connectivity problem.
Fix: Clean up guest-state console noise and root-cause the intermittent menu/search fetch failures.
PDP fails 'aria-allowed-attr' (aria-* attributes don't match their roles) and 'color-contrast' (insufficient contrast) accessibility audits.
Fix: See Accessibility category for detail; fix ARIA role/attribute mismatches and low-contrast text/buttons on the PDP template.
This audit did not capture an add_to_cart or begin_checkout GA event in the same run where the item was actually added to the bag (analytics network capture and the add-to-cart script were run separately). No Facebook/Meta Pixel (fbq) was detected at all.
Fix: Re-verify with combined instrumentation that add_to_cart, view_item, begin_checkout and purchase Enhanced Ecommerce events actually push to dataLayer/GA4; add a Meta Pixel if paid social is part of the marketing plan.
The word 'cookie' did not appear anywhere in the rendered body text on the pages visited, suggesting no consent banner/cookie notice is shown despite GA4 setting _ga/_ga_LXBXGL3R0P cookies immediately on load.
Fix: Add a cookie/consent notice (and ideally Google Consent Mode) before launch in any region with consent requirements (EU/UK/CA etc.).
'[aria-*] attributes do not match their roles' — likely an ARIA attribute applied to an element/role combination that doesn't support it (common on custom gallery/carousel or option controls).
Fix: Run axe DevTools on the PDP to find the exact offending element(s) and correct the ARIA role/attribute pairing.
Background/foreground color contrast ratio is insufficient somewhere on the PDP template.
Fix: Check price/badge/button text colors against their backgrounds (e.g. the red 'ADD TO BAG' button text, the strikethrough 'reg $X' price, and any light-gray micro-copy) with a contrast checker at WCAG AA (4.5:1 for normal text).
The footer link crawl returned 21 links, all policy/nav/duplicate-home links; no distinct social media profile URLs (Instagram/Facebook/Pinterest) or an email-capture form were detected.
Fix: Confirm whether social links/newsletter capture exist elsewhere on the page (they were not detected inside the <footer> tag); add if genuinely missing, as reference domains/handles per project rules (not the source brand's own profiles).
Cumulative Layout Shift: 0.022 (home) / 0.001 (PDP) — both well under the 0.1 'Good' threshold. Total Blocking Time: 10ms (home) / 20ms (PDP) — excellent.
Fix: No action needed; layout stability and main-thread blocking are not the problem here — startup/paint timing is.
Lighthouse flags 'Heading elements are not in a sequentially-descending order' on both Home and PDP.
Fix: Audit heading levels (h1->h2->h3) per template section; do not skip levels for styling reasons.
See SEO category for the same finding — impacts both SEO and screen-reader navigation.
Fix: Fix heading hierarchy per template.
'Image elements have [alt] attributes that are redundant text' — likely alt text duplicating adjacent visible text (e.g. alt="Website-19" next to a text logo).
Fix: Use empty alt="" for purely decorative/duplicate images, and meaningful unique alt text for content images.
GET /api/wishlists/me returns 422 'Invalid credentials' for guests; this matches the documented expected behavior, not a defect.
Fix: No action needed; consider suppressing the console.error noise for guest sessions for cleanliness.
ADD TO BAG on the pendant PDP correctly added the item; cart page showed correct qty, subtotal, discount amount and 'PROCEED TO SHIPPING'; /checkout/address rendered guest contact fields (email required, phone optional) after an item was in the cart.
Fix: None — this portion of the funnel is functioning. Full address+payment+order-confirmation was not exercised (per instructions, no real purchase/payment was attempted).
PDP has a correct self-referencing canonical and a valid viewport meta tag. robots.txt blocks /checkout/*, /my/*, faceted-filter URLs, etc. — sensible crawl-budget rules.
Fix: None.
Certificate is valid (Google Trust Services, CN=varnijewels.com likely wildcard, not-after Aug 28 2026), HTTP/2 in use via Cloudflare, and no mixed-content warnings surfaced during the walkthrough.
Fix: None — keep monitoring expiry (MANUAL/ops item, see Monitoring category).
Not observable from outside without attempting exploit-like behavior, which was out of scope for this audit.
Fix: Ops team should confirm these server-side controls exist on the shared api.varnijewels.com backend.
At 390x844 the header collapses to a hamburger, the sidenav opens correctly with the same 'Website-19' wordmark, and no horizontal overflow was visible in captured screenshots.
Fix: None from this pass; recommend a dedicated mobile-qa pass across more device sizes.
Add-to-cart, cart-subtotal/discount calculation, and checkout-address rendering all responded quickly and correctly during manual exercise. Only failing API call observed was the expected guest wishlist 422.
Fix: None from the client side.
Not observable from outside the infrastructure.
Fix: Ops team should verify against the shared api.varnijewels.com backend directly (query plans, queue dashboards, server metrics).
gtag.js loads with measurement ID G-LXBXGL3R0P; page_view and user_engagement hits were captured going to google-analytics.com/g/collect during normal navigation. window.dataLayer and window.gtag are both populated/defined.
Fix: None for basic install; verify Enhanced Ecommerce events specifically (see below).
Home is close to perfect; PDP drops due to specific failures below.
Fix: Close the gap between Home and PDP templates.
Cart/PDP sidebar shows 'Book an Appointment', 'Free Ring Sizing', 'Insured Delivery', 'Free Shipping & Returns', and the PDP shows 'Free & easy returns' and a WhatsApp chat bubble.
Fix: None; these read well for a jewelry vertical.
PDP shows 'No reviews yet / Be the first to share your thoughts' — an honest empty state rather than fake reviews, which is correct behavior, but means no social-proof signal exists yet for any product checked.
Fix: Consider seeding a modest number of real reviews once available; do not fabricate reviews.
Not observable from outside; this audit is a one-time external snapshot, not a monitoring integration check.
Fix: Confirm with ops which of these are wired up fleet-wide (e.g. uptime checks, SSL-expiry alerts for the Aug 28 2026 cert, CWV monitoring via CrUX/Search Console) vs. still to configure.
Real mobile emulation (iPhone-class (Playwright devices['iPhone 13'], 390x664 CSS viewport, DPR 3, touch, mobile Safari UA) - portrait, iPhone-class - landscape spot-check on PDP (664x390), iPhone-class - Slow4G (400kbps/400ms latency) + 4x CPU throttle full pass, Android-class (Playwright devices['Pixel 7'], 412x839 CSS viewport, DPR 2.75, touch, Chrome mobile UA) - portrait, Android-class - landscape spot-check on PDP (839x412)), touch interaction, thumb-driven journey.
Opening the hamburger drawer shows a JewelWeSell script/cursive gold logo (not the Website-19 red wordmark used in the header) plus real JewelWeSell support contact info: [email protected] and +(646) 598-7516. Reproduced on both iPhone and Pixel profiles.
Fix: Replace the drawer's logo asset and support email/phone with Website-19's own identity/placeholder; audit theme header/nav/footer components for any other leftover source-brand assets.
The primary product image request is blocked (net::ERR_BLOCKED_BY_ORB) on the cdn-cgi resize URL (media.jewelwesell.com/cdn-cgi/image/width=1280,quality=80,format=auto/stores/.../232635-0.jpg), leaving a large blank gray box in place of the hero photo. Reproduced on both iPhone and Pixel profiles.
Fix: Fix the image proxy/CDN/CORS configuration for the cdn-cgi resize path so mobile browsers can load the resized hero image.
The 'ADD TO BAG' CTA has position:static all the way up its ancestor chain (class tg-cta). On initial PDP load its bounding box sits below the visible viewport (y=867.8 vs 664px viewport height on iPhone profile), and it scrolls with the page rather than staying pinned: scrolling 600px moved the button by exactly 600px (867.8 -> 267.8), proving it is not fixed/sticky.
Fix: Wrap the PDP add-to-cart CTA in a position:sticky/fixed bottom bar on mobile, matching the pattern already used correctly on the cart page's 'PROCEED TO SHIPPING' bar.
Tapping Add to Bag gives no toast/snackbar and no detectable cart-badge update in the DOM immediately after the tap; the button itself just turns a paler/washed-out red, which reads as disabled rather than confirmed. The item IS actually added (confirmed by loading the cart page afterward), so this is a silent-success UX defect, not a broken add-to-cart.
Fix: Add an immediate toast/snackbar confirmation and animate/update the header cart badge count on successful add-to-cart.
Rotating to landscape on the PDP produces scrollWidth slightly exceeding clientWidth (iPhone: 673 vs 664; Pixel: 847 vs 839), a ~7-9px overflow producing a visible scrollbar sliver at the right edge.
Fix: Audit fixed-width elements (likely the 3-up Pickup/Delivery/Shipping info row or gallery container) for landscape overflow and clamp to 100% width.
In the Filters full-screen sheet, left-column facet-group labels are visually truncated with no ellipsis-affordance clarity, e.g. 'CENTER STONE CT...', 'SIDE STONE SETTI...', 'SIDE STONE SHAP...' - users cannot tell what the full facet name is without tapping into it.
Fix: Widen the label column, reduce font-size for long labels, or wrap text instead of clipping.
The hamburger icon's actual hit area measured 24x24px on both iPhone and Pixel profiles, below the ~44x44px thumb-target guideline for a primary, every-page nav trigger.
Fix: Increase the button's padding/hit-area to at least 44x44px without necessarily changing the visual icon size.
On product cards, the 'reg' label is orphaned at the end of the current price line while the actual struck-through original price wraps down onto its own line beneath it (e.g. '$6409.00 reg' then '$32049.00' below), reading as an incomplete/broken price at a glance.
Fix: Prevent 'reg $X' from wrapping (white-space: nowrap or restructure the price row), or intentionally stack label above price with clear spacing/styling.
The drawer's 'Shop & Explore' section lists two separate 'Home' rows back to back.
Fix: De-duplicate the nav/menu configuration entries feeding the mobile drawer.
The sampled PDP (4.00ct cartoon diamond pendant) has no color/size/metal variant chips at all - only a star-rating widget (1-5) and review/feedback tab buttons were found. The known fleet-wide risk of an invisible/low-contrast selected variant state could not be exercised on this product.
Fix: Re-run this specific check against a product that has real variant options.
Desktop viewports (1920x1080, 1440x900, 1366x768), hover states, keyboard navigation, layout integrity.
Header nav renders 7 category links (Engagement Rings, Wedding Bands, Diamonds, Necklaces, Earrings, Bracelets, Gifts) but they only resolve to 2 unique hrefs: Engagement Rings & Wedding Bands both -> /jewelry-rings; Diamonds, Necklaces, Earrings, Bracelets all -> /jewelry (Gifts -> /products, generic). Loading /jewelry directly renders 'All Products / 0 results'. Confirmed identically at all 3 desktop widths.
Fix: Wire each nav category label to its own real Meilisearch category slug (e.g. /necklaces, /earrings, /diamonds, /bracelets) per the project's slug-route convention, instead of funneling 4+ categories into one shared, empty '/jewelry' listing.
Scrolling the homepage at desktop width reveals 'The Solitaire Collection' banner and both 'Gifts they will treasure' cards (Anniversary gifts / Bridal party gifts) rendering with no image at all - just empty white space where a lifestyle/product image should fill the section, breaking the wide-screen layout balance. Network capture shows repeated 'net::ERR_ABORTED' on GET requests to media.jewelwesell.com/New_JWS/... on every page (home, PLP) across all 3 viewports (consistently ~14-16 aborted image requests per page load) - classic ORB (Opaque Response Blocking) behavior for a cross-origin hotlinked image loaded in an <img> without proper CORS.
Fix: Stop hotlinking media.jewelwesell.com. Rehost/proxy these images through static.varnijewels.com (as the main PDP/PLP product photography already correctly does) or through the app's own image proxy so the browser doesn't ORB-block the cross-origin no-cors image load.
Hovering any top-level category link (Categories, Engagement, Engagement Rings, Necklaces, Diamonds, etc.) at 1920x1080 / 1440x900 / 1366x768 produces only a text-color change (to red) - no dropdown/flyout panel appears in the DOM at any width, checked both programmatically (querying for any newly-visible [class*=mega], [class*=dropdown], [class*=submenu], [role=menu] element) and visually via screenshot. A discerning desktop shopper expects a hover-triggered megamenu with sub-category groupings on a jewelry storefront of this density (1000+ products); instead all sub-navigation is flattened into a single static second row.
Fix: Either implement a real hover megamenu with sub-category flyouts pulled from the backend menu API (per the fleet's 'megamenu from backend API' convention), or, if a flat single-row nav is the intended design for this theme, confirm that's deliberate - as-is it reads as a broken/missing interaction to a mouse-driven desktop shopper.
PDP for '4.00 ct EF VS Lab Grown Diamond Cartoon Pendant in 14k White Gold 232635' (a diamond teddy-bear pendant) shows Product Description: "...this ring showcases a rich green emerald surrounded by dazzling diamonds, all set in a finely crafted gold band..." - describes a completely different product (a ring, with an emerald, no bear motif). This is a generic/templated description that was not customized per product.
Fix: Audit the product-description generation/import pipeline for this store; ensure descriptions are generated per-product (title/gem/setting-aware) rather than reused boilerplate. This directly undermines shopper trust at the moment of purchase decision.
Clicking 'ADD TO BAG' on the PDP successfully adds the item (confirmed by navigating to /checkout/cart and seeing it there), but no toast/snackbar appears and the header cart icon shows no count badge immediately after the click, across all 3 viewports. The button itself also fades to a washed-out light-pink color after the click (screenshot: w19d-1920x1080-10-pdp-add-to-cart.png), which reads ambiguously like a disabled/error state rather than a clear 'added' confirmation.
Fix: Add an immediate toast/snackbar ('Added to bag') and update the cart icon badge count synchronously with the add-to-cart response so a desktop shopper gets instant confirmation without navigating away.
Hovering the large PDP gallery image at all 3 desktop widths produces no CSS transform/zoom or lightbox trigger (computed transform stayed 'none' before/after hover). For a jewelry storefront where shoppers want to inspect stone/setting detail, this is a missed desktop-specific polish opportunity (mouse users expect hover-zoom or click-to-lightbox, unlike mobile pinch-zoom).
Fix: Add a hover-zoom (magnifier or scale-on-hover) or click-to-lightbox interaction on the main PDP image for desktop pointer users.
Automated search for a sort <select>/button (`select[name*=sort]`, `[class*=sort] select`, `button[class*=sort]`) found nothing on 3 separate runs, despite a 'SORT / Recommended' label being visible in the PLP screenshot toolbar - it's likely a custom dropdown component whose DOM doesn't match common sort-control patterns, or genuinely non-interactive.
Fix: Verify manually that the 'SORT: Recommended' control in the top-right of the filter bar actually opens a functioning sort menu; if it's a static label, wire it up.
On /products, the 4th card in the first row ('0.66 ct ... Circle Cluster Engagement Ring... ') shows only the top sliver of a necklace/tiara image with a large blank white area filling the rest of the image box, while sibling cards show full images cleanly.
Fix: Check that product's source image asset/crop; likely a bad crop or an image with excess whitespace baked in, or a partially-failed image load.
During the 1366x768 pass, 6 additional console errors appeared beyond the expected/known wishlist 422 ('Error loading featured products: TypeError: Failed to fetch', 'Error fetching menu: TypeError: Failed to fetch', 'Search error: TypeError: Failed to fetch', etc.) that did not appear on the 1920 or 1440 passes with an identical script. Likely transient network/backend flakiness (possibly rate-limiting from rapid repeated automated navigations) rather than a hard desktop-specific bug, but flagged since it touches menu/search/featured-products reliability.
Fix: Monitor backend (api.varnijewels.com) for rate-limit or intermittent network errors under back-to-back navigation; not conclusively a desktop-QA-specific defect, worth a follow-up spot check.