Shopify Maintenance & Management

Liquid render audits on the templates that actually drive revenue, which in practice means the product detail page and the top collection templates. Asset loading tightened, render-blocking scripts deferred, above-the-fold imagery prioritised properly rather than lazy-loaded by default.

Core Web Vitals are measured against real field data, not a lab score. LCP work focuses on the hero image and the first text block on PDP; CLS work chases down the late-loading widgets that shift layout after the user has already started reading.

Most stores carry apps that nobody has reviewed since they were installed. A fair number inject scripts on every page for features used on one. App audits identify which installed apps earn their weight, which are running permissions wider than their actual function needs, and which are quietly abandoned by their developers.

Removal is careful work, because apps leave residue in the theme, in metafields, and in webhook subscriptions. The goal is a leaner, better-scoped app footprint, not a clean-slate reinstall.

Checkout extension work on Shopify Plus where the plan allows it, covering custom validations, delivery customisations, and post-purchase offers that behave the same on mobile as they do on desktop. For stores on Basic and Advanced plans, the work sits in cart behaviour, payment method configuration, and the theme-side of the funnel.

Conversion is not an app problem. It is a clarity problem, a speed problem, and a trust problem. Tooling helps. It is not a substitute for reviewing the actual path the customer walks.

Remix and Node custom and public apps kept current with the Shopify API version cadence, which moves faster than most store owners expect. Webhook handlers reviewed for reliability, retry behaviour, and idempotency, since the default assumptions in example code do not survive contact with real traffic.

API version migrations are a recurring job, not a one-off. The work includes auditing GraphQL queries against deprecation notices, replacing removed REST endpoints, and keeping scope declarations tight enough to pass review without being so narrow that the next feature breaks.

Store-to-store migrations where catalogue, customer records, order history, metafields, and app state all have to land together, not separately over a weekend. Replatforming work from WooCommerce or Magento onto Shopify, where the harder part is usually the URL structure and the redirects, not the product import.

SEO is treated as a migration constraint, not a post-migration cleanup. Canonicals, 301s, sitemap changes, and internal link audits are planned before the cutover, not patched after traffic drops.

Shopify-specific technical SEO, which mostly means working within the platform’s URL conventions rather than against them. Canonical handling across product variants and collection filters, sitemap and robots configuration reviewed against what the platform generates by default, and structured data on product and collection templates kept accurate as the catalogue changes.

Installed apps routinely hold write_orders, write_customers, or write_contentscopes when a read-only equivalent would cover what the app actually ships. Shopify’s own app review process does not catch this class of over-scoping. The result is that a compromised app is worth more than the app’s own functionality, because the scope opens the whole store to an attacker who never needed to be clever. The fix is a scope audit on every installed app, measured against its real job, with a replacement or reinstall when the delta is too wide to justify.

A nested {% section %} call inside a collection loop, or a section that hits product.metafields once per card, quietly adds several hundred milliseconds to mobile render before the hero image has begun to paint. The section system is supposed to isolate render cost. A careless section undoes that isolation, and page caching does not rescue you, because the cached HTML still carries the same render-heavy markup. The fix is flattening the render path on the templates that actually drive revenue, not caching harder.

After a Plus upgrade, or a migration onto the checkout extensibility framework, legacy checkout.liquid customisations silently stop executing. There is no admin error, no deprecation notice in the place most people would look, and the order confirmation page visually looks the same as it did on Friday. The custom validation, conversion hook, or analytics event that was running for a year simply stops firing, and the first sign is usually a finance team noticing a gap in tracked conversions a month later. Every Plus engagement gets a full checkout audit on day one, because this pattern repeats.