The problem ? the same work, four times, forever

Two recurring tasks were quietly eating the product manager's time across Army & Outdoors' 4 regional stores (NZ, AU, US, EU):

1. Image filenames for SEO

Image filenames matter for SEO ? british-army-mtp-trousers-front.jpg ranks and gets found; IMG_4823.jpg doesn't. But renaming images to SEO standards is tedious. Some products have 8 images. Some have 10. And every one of those needs the correct filename on every store. For a single 10-image product that's up to 40 manual filename edits across the 4 stores. Multiply by catalogue size and it's simply never going to get done by hand consistently.

2. Metafields drifting between stores

The product manager maintains metafields ? the structured data behind product specs, filters, custom attributes. They'd update a metafield on the NZ store (the one they work in day to day) and it would simply not exist, or be stale, on AU/US/EU. The stores drifted apart silently. Customers on the AU store saw missing or wrong spec data that was correct on NZ.

What I built ? two webhook-driven systems

System 1 ? automated image filename SEO

  • products/create and products/update webhooks fire when a product is added or changed
  • HMAC verified, HTTP 200 returned immediately, queued for processing (the standard webhook reliability pattern)
  • The processor generates SEO-correct filenames for the product's images based on the product's title/handle and image position
  • It applies the corrected filenames to that product's images on all 4 stores
  • The product manager uploads images once with whatever filename the camera/supplier gave them. The system makes them SEO-correct everywhere, automatically.

System 2 ? metafield sync across stores

  • NZ is the store the product manager works in ? the source of truth for metafield values
  • When a metafield is updated on an NZ product, the change is detected and the same metafield value is pushed to the matching product on AU, US, and EU
  • Namespaces and types are preserved correctly ? Shopify's metafield API is fiddly about these, and getting it wrong silently corrupts the data rather than erroring loudly
  • The stores stay consistent without the product manager ever touching AU/US/EU directly for metafield work

How this is different from the multi-store sync (AAOsync) case study

Worth being precise, because these sound similar:

  • AAOsync handles one-off products ? items that live only in Shopify, created once on NZ and fully replicated to the other stores. Whole-product replication for a specific category of stock.
  • This system handles the regular catalogue ? products that already exist on all stores (sourced via the normal pipeline). It doesn't replicate whole products; it keeps two specific things consistent: image filenames (for SEO) and metafields (for spec accuracy).

Different problems, different products, different systems. Both reduce the "do it four times by hand" tax.

The result

  • Product manager uploads images once. SEO filenames apply everywhere automatically. No more 40-edits-per-product filename grind.
  • Metafields stay consistent across all 4 stores. Update once on NZ; AU/US/EU follow. No more silent spec drift between regions.
  • SEO benefit compounds. Every product image across every store carries a descriptive, keyword-relevant filename ? at zero ongoing manual cost.
  • Product manager time went to actual merchandising instead of repetitive cross-store admin.

The technical bits worth noting

  • Change detection on metafields ? the sync only pushes when a value actually changed, not on every product save. Keeps Shopify API usage low.
  • Namespace/type fidelity ? Shopify metafields fail quietly if you push the wrong type or namespace. The sync preserves both exactly so AU/US/EU get valid, usable metafields, not corrupted ones.
  • Position-aware image naming ? filenames encode image order (front, back, detail, etc. by position) so the SEO naming is meaningful, not just the product title repeated 10 times.
  • Webhook + queue ? capture is instant; the heavier per-store API work runs from the queue so it never blocks product saves or hits rate limits during bulk edits.

Why this matters for your store

The pattern across all of this is the same: any task a person does once per store, per product, is a task that won't stay done at scale. It gets skipped under deadline, done inconsistently between people, or quietly abandoned. The store slowly degrades and nobody notices until SEO traffic dips or a customer complains about wrong specs.

Image SEO and metafield consistency are exactly this kind of work ? important, repetitive, invisible when it breaks. Automating them means they're always done, on every store, without anyone having to remember. I built both for a 4-store operation and they run unattended.