Website-24 — fiona theme

medium Soft-404: nonexistent slugs return HTTP 200 with a generic listing instead of a real 404 SEO (technical)

GET /this-page-does-not-exist-xyz123 returns HTTP 200 with <title>Products</title> (an empty/generic product-listing shell) rather than a 404. This is a side effect of the bare [slug]-as-listing route convention, but it creates Google Search Console 'soft 404' signals at scale.

curl -o /dev/null -w '%{http_code}' → 200; page title 'Products'

Fix: Return a real 404 (or noindex) when a slug matches zero categories/products, distinct from a valid empty-filter state.

medium Enhanced Ecommerce events unverifiable Analytics & Tracking

Because Add to Cart is broken, add_to_cart/begin_checkout events could not be confirmed. No Meta/Facebook Pixel (fbq) detected.

w24-analytics.json fbq:false; broken cart flow

Fix: Re-verify GA4 ecommerce events once the cart bug is fixed; add a pixel if the business wants paid-social retargeting.

medium Newsletter block is enabled but has no configured copy Marketing Readiness

Site settings show newsletter:{active:true, placeholder:'', heading:'', subheading:''} — the capture block is turned on but every text field is blank, which likely renders an empty/blank section or nothing visible.

grep of homepage SSR payload for 'newsletter'

Fix: Populate the newsletter heading/subheading/placeholder copy, then verify it renders and actually captures an email.

medium Footer contact info is placeholder, not real Marketing Readiness

Footer phone '+91 90000 00000' is an all-zero placeholder; footer email '[email protected]' uses the reserved, non-deliverable .example TLD.

w24-cart2.png footer

Fix: Replace with this store's real, monitored support phone/email before launch.

medium Remove-item (trash) icon and close-cart (X) icon are under 44x44 Cart drawer

'Remove item' trash icon measures ~23x34px; 'close cart' X measures ~25x36px. Both are icon-only buttons with no visible padding buffer.

Open the cart drawer after add-to-cart on either device profile; measure via getBoundingClientRect(): Remove item {w:23.3,h:34}, close cart {w:24.7,h:36}.

Fix: Add invisible padding to reach 44x44 hit area on both icon buttons; the close action is lower risk since tapping the backdrop likely also closes the drawer, but the trash/remove icon is a destructive action and deserves a comfortable target.

medium Product images render as blank grey placeholders for the first ~2-3 seconds after PLP load PLP

On initial screenshot capture (~2.5s after navigation) all product card images on the /rings PLP were still blank grey boxes with only the wishlist heart icon visible; a follow-up check confirmed the underlying <img> tags do use loading="lazy" and do load correctly (naturalWidth 1280) a couple seconds later. There is no skeleton/shimmer placeholder during this gap, so on a real phone (especially with any added latency) the grid reads as broken/empty for a noticeable moment.

Navigate to https://website-24.varnijewels.com/rings on iPhone 13 emulation and screenshot at ~2.5s post-navigation vs ~4s - grey boxes vs loaded photos.

Fix: Add a skeleton/shimmer background on product-card image containers while the lazy image loads instead of plain grey, and consider prioritizing (loading="eager", fetchpriority=high) the first 4-6 above-the-fold PLP images.

medium This PDP only exposes 1 image (no swipeable gallery) - swipe/pinch-zoom could not be exercised PDP gallery

The sampled PDP (first product in /rings) has galleryDotCount=1 and the 'Next slide'/'Previous slide'/'Close Carousel' controls exist in the DOM but are 0x0/hidden - i.e. genuinely only one product photo is attached, there is nothing to swipe between. This is a content/catalog gap rather than a gallery-code bug (the carousel infrastructure is present and presumably works once >1 image exists), but for a lab-grown-diamond jewelry storefront a single static image per product (no macro/angle/on-hand shots) undersells the product on mobile where zoom is the main way to inspect detail.

Open the same PDP; document.querySelectorAll('button[aria-label*="Go to slide"]').length === 1; 'Next slide' button getBoundingClientRect() = 0x0.

Fix: Backfill multi-angle product photography (or at minimum a rendered alt-angle) for catalog SKUs so the built-in swipe/carousel component actually has multiple slides to page through on mobile; not an engineering fix.

medium Filter/Sort controls are easy to miss - sit in a low-contrast bar below the fold with no icon-first affordance issue but were not detected by any of the common selector conventions PLP

Sort By / Filter DO exist as a sticky-looking bar under the product grid ('Sort By: Recommended' / 'Filter'), each tap target 195x47 - comfortably sized. This is a PASS on tap-target size, listed here only because the bar sits visually disconnected from the grid content (no border/shadow separating it from the page background at the bottom) and could be mistaken for footer text rather than an interactive control.

Screenshot /rings on iPhone 13 - the Sort/Filter row appears as plain grey text with small icons, no button-like affordance (no border, background fill, or shadow).

Fix: Give the Sort/Filter bar a visible container (background fill or top border) so it reads clearly as tappable UI rather than page footer text.

medium No error toast/message would ever be shown if add-to-cart silently fails - only path to notice is the slide-over failing to open PDP / Add to cart feedback

On success, the app opens a 'Your Cart (N)' slide-over immediately (good, app-like feedback). No dedicated toast/snackbar/aria-live region was found on the page ([class*=toast], [class*=snackbar], [role=status], [role=alert] all absent). If the previously-documented cart-API 400/404 does occur on a future/real request, the customer's only signal that anything went wrong is that the cart drawer never appears - there is no explicit 'Something went wrong, please try again' message. On a slow connection this reads as 'nothing happened,' inviting repeated taps.

Inspect DOM for toast/snackbar/status/alert roles after tapping Add to Bag on either device profile - none found; behavior is inferred from the known desktop 400/404 case in w24-pdp-full.json where the button click produced no visible error state either.

Fix: Add an explicit error toast (e.g. 'Could not add to bag, please try again') triggered on any non-2xx response from the add-to-cart request, so failures are never silent on mobile.

medium No toast or aria-live/role=status/role=alert element exists anywhere in the DOM — failed add-to-cart is silent feedback/accessibility

When the 400/404 add-to-cart failure above occurs, there is no visual signal to the shopper at all; the page looks unchanged. Confirmed by DOM inspection during each failed-add screenshot.

Trigger a failed add-to-cart (see cart defect above) and inspect the DOM for any error-surface element — none found.

Fix: Add an explicit error toast/banner shown on any non-2xx response from the add-to-cart call.

medium Product cards show zero hover affordance on desktop plp

Hovering the first product card on /rings produced no change in computed transform or box-shadow at 1920, 1440, or 1366 — only the always-visible wishlist heart icon is present. No quick-add/quick-view reveal, no elevation/shadow shift.

Load /rings at any desktop width, hover the first product card, compare getComputedStyle(transform/box-shadow) before vs after hover — identical.

Fix: Add a hover elevation/shadow or a quick-add/quick-view reveal consistent with desktop-shopper expectations for a premium jewelry PLP.

Refined Add to cart is completely broken (POST line-items 400, GET cart 404)

Launch-readiness saw it fail; mobile QA saw it succeed cleanly on the same PDP. Desktop QA ran 6 attempts across 2 products and 2 viewports: 3/3 failed at 1920x1080; at 1440x900 one succeeded, one failed with 400, one was blocked by a stale overlay. Conclusion: intermittent, not consistently broken — consistent with a backend cart-id race.

Action: Still a launch blocker. Needs a backend fix, not a theme fix.