Skip to content
Store slow, dated, or hard to edit? Request a Store Diagnostic
Running B2B on spreadsheets or email? Plan Your B2B Project
Maintenance & Support

Shopify Theme Code Review: What a Developer Actually Checks For

You’ve inherited a Shopify store. Maybe you’ve taken on a new client, hired an in-house developer, or switched agencies after a previous relationship ended badly. Before anyone touches a single line of code, there’s a question that has to be answered honestly: what’s actually in this theme?

Not what the store looks like on the front end, that part’s usually fine, or at least good enough to have been live. The question is what’s underneath: how the theme is built, whether it follows Shopify’s current conventions, how many workarounds and hacks have been layered in over time, and whether it’s safe to build on without inheriting someone else’s technical debt as your own.

This is what a theme code review actually involves. It’s not a vague “does it look okay” pass, it’s a structured check against a specific set of criteria that determines whether a theme is a solid foundation or a liability. Here’s what we actually look for.

Theme Architecture and File Structure

The first thing a proper review checks is whether the theme follows Shopify’s current architecture or an older, more rigid pattern. Since Shopify introduced Online Store 2.0, themes are meant to be built around JSON templates, reusable sections and blocks, with merchant-editable settings defined in settings_schema.json. This structure is what lets a store owner rearrange homepage sections or swap a block in the theme editor without a developer touching code.

A review at this level checks:

  • Whether templates are JSON-based (.json) or still .liquid-only, which limits what can be edited through the theme customiser
  • Whether sections are genuinely reusable, or whether near-identical sections have been duplicated with slightly different names for each page
  • Whether snippets are used sensibly for shared markup, or whether the same block of Liquid is pasted across a dozen files
  • Whether the config/settings_schema.json file is coherent, or bloated with abandoned settings from features that no longer exist

A theme built on the older structure isn’t automatically broken, but it’s a signal the theme hasn’t been updated in a while, and it constrains what a merchant’s marketing team can safely change themselves without a developer.

Liquid Code Quality

This is where a review spends the most time, because Liquid quality is the clearest signal of how the theme has been maintained. Specific things we check:

  • Hardcoded values where a setting should exist, colours, text strings or URLs baked directly into .liquid files instead of being exposed as theme settings or metafields
  • Deprecated Liquid objects and tags that Shopify has phased out or replaced, which can produce silent errors or unexpected output
  • Inconsistent or missing {% comment %} documentation in genuinely complex sections, making the logic hard to follow for the next developer
  • Nested loops and conditionals that could be simplified, which usually indicates the code has been patched repeatedly rather than refactored
  • Scattered inline styles and inline <script> tags instead of centralised CSS and JS files, which makes both performance and maintenance harder

None of these individually breaks a store. Collectively, they tell you whether you’re looking at a theme that was built with discipline or one that’s been duct-taped together update after update.

Performance

Performance issues in a theme are rarely one big problem, they’re usually a dozen small ones stacking up. A review checks:

  • Whether images use Shopify’s responsive image tags (image_url with appropriate sizing and srcset) or are served as single oversized files regardless of device
  • Whether JavaScript and CSS are render-blocking in the <head>, or deferred/loaded appropriately
  • Whether third-party app scripts are loaded synchronously and stacking up load time, particularly ones that were installed once and never removed
  • Whether fonts are loaded efficiently or pulling in unnecessary weights and styles
  • General Core Web Vitals health, Largest Contentful Paint, Cumulative Layout Shift and interaction responsiveness, as a proxy for how the accumulated code is actually affecting real users

A theme that looks fast in a casual click-through can still be quietly leaking performance through a dozen small inefficiencies that only show up under proper testing.

Apps vs Hardcoded Hacks

One of the more revealing checks is looking at where functionality lives. Two failure patterns show up constantly in inherited themes:

  1. Functionality hardcoded into the theme that should be an app, a custom subscription flow or complex product configurator built directly into Liquid and JavaScript by a previous developer, with no ongoing support, that’s now fragile and undocumented.
  2. Functionality forced through an app that would be better as a native theme feature, simple things like a size chart or an announcement bar handled by a heavyweight app, adding an extra script, an extra dependency and an extra thing that can break, when a lightweight section would do the job with no external dependency at all.

Neither pattern is automatically wrong, but both carry a cost, and a review should be able to explain, feature by feature, why something was built the way it was, or flag that nobody currently can.

Version Control and Deployment Process

This one isn’t about the code itself but about how it’s managed, and it matters just as much. A review checks:

  • Whether the theme is connected to a proper version control workflow (Shopify’s GitHub integration, or a similar setup), or whether changes have been made by editing live theme files directly in the Shopify admin code editor
  • Whether there’s any history of what changed, when, and why
  • Whether a duplicate/staging theme was used to test changes before publishing, or whether the live theme has been edited directly
  • Whether multiple developers have worked on the theme without any coordination, leaving conflicting or overwritten changes

A theme with no version control isn’t just harder to maintain, it’s a real risk. If something breaks, there’s no way to see what changed or roll it back cleanly.

Duplicate and Unused Code

Themes accumulate weight over time, and it rarely gets cleaned up. A review flags:

  • Sections, snippets and templates left over from features that were removed or replaced but never deleted
  • Duplicate CSS classes and rules doing the same job with slightly different names
  • Metafields defined and populated but no longer referenced anywhere in the theme
  • Unused JavaScript files still being loaded on every page

This dead weight doesn’t just slow the theme down, it makes every future change riskier, because a developer can’t always tell at a glance whether a given file is actually load-bearing or safe to delete.

Accessibility

Accessibility gets checked as a standard part of a proper review, not as an afterthought:

  • Whether images have meaningful alt text, not left blank or filled with the filename
  • Whether the theme uses semantic HTML (proper heading hierarchy, <button> and <nav> elements) rather than generic <div>s with click handlers standing in for interactive elements
  • Whether colour contrast on text and buttons meets basic readability standards
  • Whether custom components, accordions, modals, carousels, are keyboard-navigable and carry appropriate ARIA attributes

Beyond being good practice, this is increasingly a compliance consideration for merchants selling into markets with accessibility expectations, and it’s one of the easiest things to overlook in a theme built primarily for visual polish.

Security

The security check focuses on a handful of specific risks:

  • Any API keys, access tokens or credentials hardcoded directly into theme files, where they’re visible to anyone who views page source
  • Outdated JavaScript libraries (an old jQuery version, for instance) with known vulnerabilities
  • Third-party scripts injected into the theme with broader access or reach than their function requires
  • Form handling that doesn’t validate or sanitise input properly before it’s submitted

Nexly’s Practical Theme Code Review Checklist

Pulled together, this is roughly the sequence we work through before taking over an inherited theme:

  1. Confirm whether the theme uses Online Store 2.0 architecture (JSON templates, sections, blocks) or an older Liquid-only structure
  2. Check for duplicated sections, snippets and hardcoded values that should be theme settings
  3. Scan for deprecated Liquid objects and inconsistent code patterns
  4. Run a performance check, image handling, render-blocking scripts, Core Web Vitals
  5. Map which features are hardcoded vs app-driven, and whether that split makes sense
  6. Check for version control, or the absence of it, and how changes have historically been deployed
  7. Identify duplicate and unused code adding weight without function
  8. Review accessibility basics, alt text, semantic markup, contrast, keyboard navigation
  9. Check for exposed credentials, outdated libraries and over-reaching third-party scripts
  10. Document findings against what it would cost, in time and risk, to build on top of the theme as-is versus rebuilding key parts

When to Bring In a Specialist

Some of this checklist you can do yourself with access to the theme code editor and a bit of patience, checking for obvious duplicate sections or missing alt text doesn’t require deep Liquid expertise. But properly assessing architecture decisions, performance root causes, and security exposure across an entire theme is a different level of work, and getting it wrong in either direction is costly: overestimating a theme’s problems means paying for an unnecessary rebuild, underestimating them means inheriting bugs, security gaps and a slow site you’ll be fixing for months. This is exactly the kind of assessment a Shopify audit is built for, a structured review that tells you precisely what state a theme is in before you commit to building on it.

FAQ

How long does a professional theme code review take?
For a standard theme, a thorough code review typically takes a few days of focused developer time, depending on how large and customised the theme is. Highly customised or older themes with years of accumulated changes take longer to review properly than a recently built theme with a clean structure.

Can I get a theme code review without switching agencies?
Yes. A code review is a diagnostic exercise, not a commitment to change providers, plenty of merchants commission one to understand what state their current theme is in, whether that’s to negotiate with their existing developer, plan a future rebuild, or simply get an independent second opinion before making a decision.

What’s the difference between a theme code review and a full Shopify audit?
A theme code review focuses specifically on the codebase, architecture, Liquid quality, performance and security within the theme itself. A broader Shopify audit typically covers the theme as one component alongside SEO health, app permissions, tracking and analytics setup, and overall store configuration. If you’re taking over a store rather than just a theme, the broader audit is usually the more useful starting point.

Do I need a code review if my theme is a paid marketplace theme, not custom?
Often yes, particularly if it’s been heavily customised since purchase. A marketplace theme starts from a clean, tested base, but years of ad hoc edits, added apps and section duplication can leave a purchased theme in a similar state to a fully custom one. The starting point matters less than what’s happened to it since.

What happens if the review finds serious issues?
It depends on what’s found and how deep it runs. Sometimes targeted fixes are enough, cleaning up duplicate code, fixing performance bottlenecks, patching security gaps. In other cases, particularly with older Liquid-only themes or ones with fundamentally unsound architecture, a partial or full rebuild ends up being more cost-effective than continuing to patch around the underlying structure. A good review will tell you honestly which situation you’re in rather than defaulting to the more expensive option.

Next Step

If you’re about to take over a Shopify store and don’t yet know what’s actually in the theme, get a clear picture before you commit to building on it. Book a call with Nexly or start with a Shopify audit to find out exactly what state your theme is in.

Niraj Raut
Written by Niraj Raut SEO Manager

Niraj Raut is the SEO Manager and co-founder at Nexly. He helps Australian Shopify and Shopify Plus brands earn durable organic growth through technical SEO, search-led store architecture and content that ranks. He writes about what actually moves rankings for ecommerce.

Connect on LinkedIn
Have a Shopify project? Chat with us, takes 30 seconds.