Shopify Developer for Jewelry Stores: What a Fine Jeweler Needed Fixed

TL;DR: On Enea Studio, a fine jeweler on Shopify with 476 products and 191 collections, the problems were jewelry-shaped. One Liquid filter created 25,285 duplicate product links, gold colors sold as separate products broke the gallery, and photos were sized wrong in both directions. Six sprints took real-user Core Web Vitals to 5 of 5 green. Hire the developer who reads your product data before writing code.

The rings looked pixelated on the client’s desktop monitor. On the same store, the collection grid downloaded photos three times bigger than the cards could show.

Opposite symptoms, one cause: the theme gave the browser the wrong image size information, once too small and once too large. If you run a jewelry brand on Shopify and you are about to pay someone to “make it faster”, this is the audit, the fix order and the six questions that come out of it. The limit up front: none of this moves sales on its own if the photography and pricing are not already right.

Download the Shopify jewelry store fix checklist (PDF)

Why this matters for your store

• Jewelry catalogs carry many overlapping collections (by metal, stone, style, gift), and every overlap multiplies duplicate URLs Google has to sort out.
• Metal and karat choices are where a ring buyer decides, so a gallery that shows the wrong gold color costs you the sale at the last step.
• Jewelry photos are big, detailed files, so a wrong image size costs more here than on almost any other product type.

What does a Shopify developer fix first on a jewelry store?

Enea Studio is a fine jewelry brand handcrafted in Athens. Before touching code, I crawled all 679 sitemap URLs: 476 products, 191 collections, 10 pages and 2 articles. Every URL returned 200, so nothing looked broken from the outside.

The crawl found four problem groups. Here they are in the order I would fix them on any jewelry store:

The order matters. URLs come first because Google crawls them every day. Images come second because they are the cheapest speed win, and apps come last because they need the owner’s sign-off.

Why do jewelry collection pages create duplicate product URLs?

Most Shopify themes build product card links with the Liquid within filter. It turns /products/diamond-ring into /collections/rings/products/diamond-ring. Shopify’s own reference page warns that both URLs carry the same content and says to consider the SEO implications.

On a jewelry store, that warning compounds. The same ring can sit in a stone collection, a style collection and a metal collection, and each one mints its own copy of the link. Enea’s theme used the filter 15 times across 5 product card snippets, which produced 25,285 duplicate links, about 132 per collection. The worst page, the lab-grown diamond rings collection, carried 195.

Canonical tags pointed to the clean URL, so many developers stop there. Google calls rel="canonical" a strong signal, not a command, and its duplicate URL guidance says to link to the canonical URL when linking within your site. The fix was one line per instance:

{%- comment -%} snippets/product-card.liquid {%- endcomment -%}
<a href="{{ product.url }}">

The surprise came from the speed audit. The collection-path version of a product page scored 24 on mobile Lighthouse, the worst page tested, with a CLS of 0.251. The canonical version of the same product scored 38. The SEO fix was also a speed fix.

Filter and sort URLs got the second half of the cleanup. The store had no robots meta tag on any page, so every ?sort_by= and filter. combination was open to crawling. A conditional noindex on those URLs kept them out of search results while the clean collection pages stayed indexed. My Shopify duplicate content guide has the full decision tree for ?variant and pagination URLs.

Why does the metal picker break the product gallery?

Enea does not sell 14k Yellow Gold and 18k White Gold as variants of one product. Each metal is its own Shopify product, linked to its siblings by two metafields. Many fine jewelers build it this way, because each metal needs its own photos, its own description and often its own SEO title.

Shopify has a native answer, the Combined Listings app, but it is available only on Plus and enterprise plans. Below Plus, jewelers need custom code for this. Enea links its metals with custom theme code too, and that code is where the gallery broke.

When the client asked for a 2-column 4:5 product grid in place of the carousel, the grid started showing photos for every metal at once. My first fix used variant.featured_media, Shopify’s built-in link between a variant and its image. It failed: every product in the store had that field empty. The store had never used it. That cost a full day, and it is the most useful lesson in the whole engagement.

The working fix passed an explicit is_current_product flag into the media snippet, because Liquid’s render scope cannot see the parent product variable. Two more passes handled the first page load and the products that were not merged at all.

Sprint 4 fixed the words next to the photos. Descriptions held placeholders like “18k/Sterling Silver” that the theme rewrote per metal, but it had no 18k support at all. Selecting 18k White Gold printed the raw placeholder, and partial swaps left text like “18k/14k Solid White Gold”. The swap runs twice, once in Liquid on page load and once in JavaScript on variant change, so both chains had to change together.

Why are jewelry product photos either blurry or too heavy?

Every responsive image needs two attributes. srcset lists the files available, and sizes tells the browser how wide the image will display. Shopify’s image_tag filter builds the srcset for you, but the theme sets the widths and the sizes value, and both can be wrong.

On the product page, the grid rendered photos at about 490 to 590 CSS pixels while sizes claimed 303 to 369. The browser believed it, fetched the smaller file and stretched it. That was the blur the client saw. Correcting one value fixed it, with no new photography.

On the collection grid, the problem ran the other way. The smallest width in the list was 900px, while a mobile card rendered at about 154 CSS pixels. Even a 3x retina phone needs only about 462px, so every card downloaded a file roughly three times too large. Adding widths from 180px up saved about 280 KiB per collection page on mobile.

Two smaller image bugs are worth checking on your own store:

• Press logos for Vogue, Brides and Harper’s Bazaar loaded as 2000x500 PNGs to display at about 100x26. Requesting a 300px version saved about 120 KiB per product page, with no visible change.
• The first collection image carried a hardcoded loading="lazy", which put a 4,960ms resource load delay in front of the LCP. A web.dev study of lazy-loaded LCP images on WordPress sites found that turning lazy loading off for them cut LCP by 15% on mobile archive pages.

Which apps slow a jewelry store down, and what could the theme not fix?

Here is the part most speed proposals leave out. After every theme fix, third-party apps still made up about 60% of the JavaScript payload and 1,526 KiB of unused code. No theme change could remove that.

I wrote a scope document before the sprint that named these apps as out of scope, and set a lab target of 60 to 70 on mobile. When the client asked during the sprint whether the score could go lower, the answer was already on paper. Later in the engagement, removing the Smile.io block took roughly 390KB and two seconds of processing off a collection page. If you are weighing loyalty apps, my Smile.io vs LoyaltyLion vs Growave comparison shows what each one costs in blocking time.

What did six sprints change in real-user data?

Before the work, desktop failed Core Web Vitals in Chrome UX Report field data, with LCP at 2.6s and CLS at 0.12. Both sat just over Google’s lines. Mobile passed, which is why the problem was easy to miss. After the sixth sprint, the product page passed all five metrics on real-user data:

The LCP, INP and CLS lines come from web.dev’s Core Web Vitals reference, measured at the 75th percentile of real visits. FCP and TTFB use the PageSpeed Insights lines.

The mobile Lighthouse lab score on the same product page read 23. The client’s own summary put it plainly:

“The Lighthouse lab score (23 on mobile) is low, but as you correctly identified, it’s almost entirely driven by third-party app scripts.”

Voukolos Tasatzis, Enea Studio

I explain why the two numbers split so far apart in Lighthouse vs CrUX.

Where did the fixes go wrong first?

Three changes failed before they worked, and each one is a question to ask your developer.

Deferring jQuery 3.7.1 broke the related products carousel, because a trust icons snippet loaded its own jQuery 3.4.1 with Slick attached. Removing a preconnect that Lighthouse called unused blanked a whole section. And batching two small fixes into one commit made a broken “Matches Perfectly With” section impossible to trace, so every later change shipped as its own commit.

A developer who reverts fast and tells you why is safer than one who never reports a failure.

What should you ask a Shopify developer before hiring them for a jewelry store?

Take these from the engagement above, not from a generic list:

• Ask how they will check your product data before writing code. Listen for “I will look at a product’s JSON first.”
• Ask whether your product cards use the within filter, and what they would do about it.
• Ask how they would handle metal options: variants, Combined Listings on Plus, or linked products.
• Ask what they put in a scope document, and which apps they would call out of scope.
• Ask whether they judge results by field data or the Lighthouse score.
• Ask for one change per commit, with a staging theme before anything goes live.

My 12 questions to ask before hiring a Shopify developer covers the general ones, with red-flag answers. On price, I bill a published $50 an hour, and the Shopify expert cost breakdown shows what the same work runs at agency rates.

How do you check your own jewelry store in 5 minutes?

1. Open any collection page, right-click and choose View Page Source, then search for /collections/ followed by /products/. Any match means your cards link to duplicate URLs.
2. Run one product page through PageSpeed Insights on mobile. Read the field data panel first, then find the LCP element in Diagnose.
3. In Chrome DevTools, inspect a collection card image and compare its rendered width with the file it loaded. A 154px card loading a 900px file is the 3x bug.

Run step 1 today. It takes two minutes, and on this store it found the problem behind 25,285 links.

The takeaway

• Read a product’s data before any code changes, because the jeweler’s gallery fix lost a day to an empty field.
• Replace the within filter in product cards so every collection links to one clean product URL.
• Match image sizes and widths to the real rendered card, in both directions.
• Scope app JavaScript out in writing before a speed sprint starts.
• Judge the work by real-user Core Web Vitals, not the lab score.

I am Kaspian Fuad, a Shopify developer and CRO consultant. The Enea Studio case study has the full code for every fix above. If you run a jewelry store and want this audit on yours, send me your store URL and I will tell you which of the four problems to fix first.