Shopify 2.0 vs 1.0: The SEO Differences That Actually Matter

What Shopify 2.0 is

Online Store 2.0 launched in June 2021. It bundles four architectural shifts: sections available on every template (not just the homepage), first-class metafield definitions with types and validation, JSON template files that replace top-level Liquid templates, and app blocks that let apps ship section-level UI without editing theme code. Every officially-supported Shopify theme released since - Dawn, Sense, Craft, Refresh, Studio, Ride - is 2.0-native. Older paid themes (Impulse, Prestige, Warehouse) all now ship 2.0 versions; the old 1.0 versions are still in the wild on stores that never migrated.

Shopify's own developer documentation frames 2.0 primarily as a merchant-editing and developer-experience upgrade: less reliance on developers for day-to-day page changes, faster theme development cycles, and a cleaner separation between what an app owns and what the theme owns. Those are real benefits, but they are not SEO benefits in themselves. The SEO case for 2.0 has to be made on the three specific technical changes covered below - not on the general "it's newer" argument that most upgrade guides lean on.

Confusingly, "2.0" is not a Shopify plan tier or an admin toggle - it is purely a theme architecture. A store can sit on the highest Shopify plan and still run a 1.0 theme if nobody has migrated it, and a store on the entry-level plan can run a fully 2.0-native theme like Dawn from day one. Whether a merchant is on 2.0 depends entirely on which theme is currently published, which is why the version detector further down this page checks the theme files directly rather than anything account-level.

It matters which theme you're on because 1.0 themes receive no new Shopify platform features going forward. Shopify hasn't announced a hard sunset date for 1.0 themes, but new checkout extensibility, new native app-block capabilities, and new metaobject features all ship 2.0-only. If your store is still on a 1.0 theme, you're not just missing today's SEO upside - you're falling further behind with every Shopify platform release.

Difference 1: Sections everywhere

In 1.0, sections only worked on the homepage - every other template (product, collection, article) was a static Liquid file. In 2.0, any template can host sections. For SEO this unlocks two things: (1) editorial content blocks on product and collection pages, giving you a home for the above-fold copy that lifts collection rankings; (2) metafield-driven schema sections that inject FAQPage and Review JSON-LD without touching theme.liquid on every rebuild.

The practical difference shows up fastest on collection pages. On a 1.0 theme, adding a paragraph of category copy above the product grid means a developer editing collection.liquid directly, and every future change goes through the same route. On a 2.0 theme, that same copy lives in a section block that any content editor can add, reorder, or A/B test from the theme editor. Above-fold vs below-fold copy testing - the kind we cover in our collection page copy and category content work - becomes trivial: it's a section reorder, not a Liquid rewrite. That single change is often the difference between a store running its first collection-page copy test in a week versus never running one at all, because the developer bottleneck disappears.

The same logic applies to schema. A FAQ section built as a 2.0 section block, wired to a metafield definition, can be dropped onto every product template in the catalogue in one theme edit - and every product's FAQ content, entered by a non-technical team member in the product admin, feeds FAQPage schema automatically. On 1.0, the same outcome needs either a bespoke app or a developer hard-coding FAQ blocks per template family. Sections everywhere is the unlock that makes the second 2.0 difference - metafield definitions - actually deployable at catalogue scale rather than as a one-off.

There's a content-ownership shift here too, which is easy to underestimate. On a 1.0 store, marketing teams routinely ask developers to add a paragraph to a product page and wait days for a deployment slot. On a 2.0 store, that same paragraph is a section a content editor drags onto the template themselves. We've seen this single change move a client's collection page copy testing cadence from roughly one change per quarter to weekly iterations, simply because the bottleneck - a developer's calendar - was removed from the loop. That cadence increase compounds: more tests run means more winning variants found means more collection pages carrying stronger above-fold copy sooner.

Difference 2: First-class metafield definitions

Pre-2.0, metafields existed but were untyped free-text bags managed via API or third-party apps. In 2.0 they're first-class: type-checked, editable in admin, and referenced natively in themes. For SEO this is where the compounding returns live - dynamic schema, dynamic internal linking, and dynamic FAQ content all key off definitions you set up once and populate per product.

On one anonymised client migration we ran from 1.0 to 2.0, moving Product schema generation from hard-coded theme values to metafield-driven definitions lifted the Google Rich Results Product schema pass rate by 15 percentage points across the catalogue - because product-level fields that were previously missing or inconsistent (review counts, availability nuances, GTIN) became mandatory, typed fields that content editors couldn't skip or mistype. That's the real payoff of typed metafields: fewer schema validation failures, not a novel schema type you couldn't get before.

Three metafield definitions to install first - copy the JSON straight into a metafield definition import, or recreate them via Settings → Custom data:

{
  "name": "Product FAQ",
  "namespace": "custom",
  "key": "faqs",
  "type": "list.metaobject_reference",
  "description": "Question/answer pairs used to render FAQPage schema on the product template."
}

{
  "name": "Review rating",
  "namespace": "reviews",
  "key": "rating",
  "type": "number_decimal",
  "description": "Average star rating, drives AggregateRating schema."
},
{
  "name": "Review count",
  "namespace": "reviews",
  "key": "rating_count",
  "type": "number_integer",
  "description": "Total review count, drives AggregateRating schema."
}

{
  "name": "Collection editorial",
  "namespace": "custom",
  "key": "editorial",
  "type": "rich_text_field",
  "description": "Above-fold editorial copy block for collection templates."
}

Set these up before you migrate a single product's content. Populating a metafield after the definition exists is a bulk CSV import; populating it after products have already gone live on the new theme without the definition means re-entering the data by hand, product by product. This ordering point alone accounts for most of the wasted hours we see in rushed 1.0 to 2.0 migrations.

Metafield definitions also change how internal linking scales. A "related reading" or "buying guide" metafield that references other products or articles by ID means the storefront can render contextual internal links without a developer maintaining a manual list. On a catalogue running into the thousands of SKUs, that's the difference between internal linking that's maintained once at the definition level and internal linking that quietly rots because nobody has time to update hard-coded link lists as the catalogue changes. It's a smaller win than the schema gain, but it's the one that keeps paying out as the catalogue grows rather than depreciating.

Difference 3: JSON template files

2.0 templates are JSON files that reference sections by ID, instead of monolithic Liquid files. The rendered HTML is cleaner (no leftover Liquid whitespace and conditional cruft), the section order is admin-controlled per template, and every section is code-split - you ship only what a template uses. Side-by-side, the shift is small in appearance and large in maintainability. Here's the same product template expressed both ways - copy either to see the actual code:

{
  "sections": {
    "main": { "type": "main-product" },
    "faq":  { "type": "product-faq" },
    "reviews": { "type": "product-reviews" }
  },
  "order": ["main", "faq", "reviews"]
}

{% comment %} product.liquid - 1.0 style {% endcomment %}
<div class="product-page">
  {% section 'main-product' %}
  {% if product.metafields.custom.faqs %}
    {% include 'product-faq' %}
  {% endif %}
  {% include 'product-reviews' %}
</div>
{% comment %} Section order is hard-coded here.
   Reordering means editing this file directly. {% endcomment %}

The Liquid version hard-codes section order and wraps every optional block in an if-statement that has to be maintained by hand. The JSON version separates "what sections exist" from "what order they render in" - reordering the FAQ and reviews sections on the JSON template is a drag in the theme editor; doing the same on the Liquid template means editing the file and redeploying. For SEO specifically, the practical win is markup cleanliness: JSON templates don't carry forward the accumulated Liquid whitespace and dead conditional branches that build up in long-lived 1.0 templates, which marginally helps page weight and Core Web Vitals scores - see our Shopify page speed guide for the fuller picture on rendering performance.

There's also a resilience argument for JSON templates that doesn't get made often enough. Because a JSON template only declares which sections exist and in what order, a broken or removed app block degrades gracefully - the section simply doesn't render, rather than throwing a Liquid syntax error that can take down the whole template. On a 1.0 theme, a single malformed conditional in a shared Liquid file can knock out rendering for every product on the store simultaneously. That's a rare failure mode, but when it happens on a 1.0 theme it happens at the worst possible scale.

Non-SEO 2.0 features worth noting

App blocks (apps ship section-level UI, merchants place them from the theme editor), checkout extensibility (post-Checkout.liquid), and a better dev experience via Shopify CLI and the theme dev server. None of these affect ranking directly; all of them reduce the friction of shipping the SEO work you actually want to ship, because fewer changes require a developer and a deployment window.

1.0 vs 2.0 comparison table

Migration checklist: 1.0 → 2.0 for SEO

Twelve steps, in order. Skipping the ordering - particularly setting up metafield definitions before content migration - is the single most common cause of rework we see on client migrations.

1. Back up the current theme (download .zip). Store it - you'll roll back to it if migration goes wrong.
2. Choose a 2.0-ready theme. Dawn is the safe default for SEO-first migrations.
3. Recreate template structure section-by-section on the new theme.
4. Migrate section-level customisations (colours, fonts, layout order).
5. Set up all metafield definitions BEFORE content migration - schema and editorial blocks depend on them.
6. Migrate schema (Product, Article, Organization) into the new theme - see the structured data article.
7. Verify canonical strategy is still applied (see the canonical tags article).
8. Verify robots.txt.liquid customisations carried over (see the robots.txt article).
9. Verify sitemap generation is unchanged.
10. Test on the preview URL before publishing - use ?preview_theme_id= in Search Console URL Inspector to pull the preview into a rendered fetch.
11. Publish, then watch Search Console daily for the first two weeks - spikes and dips both.
12. Announce internally so the team stops applying edits to the old theme.

Timing matters as much as sequencing. We generally recommend running this checklist alongside a planned theme refresh rather than as a standalone SEO project - the disruption cost of a theme change is paid once either way, so folding the 2.0 migration into a redesign you were already scheduling gets you the SEO upside without a second round of risk. This is the same logic we apply to the complete Shopify SEO guide's broader technical roadmap: sequence disruptive changes together, not apart.

Budget more time than the checklist implies for step three - recreating template structure section-by-section. This is where the bulk of the developer hours go, particularly on stores with heavily customised 1.0 templates that mix bespoke Liquid logic with third-party app snippets. Audit every app embed on the current theme before you start, because some 1.0-era apps ship Liquid snippets that assume a 1.0 template structure and need an app-side update or a native 2.0 app block replacement to keep working post-migration.

What NOT to change during migration

Migrations fail on SEO not because of anything specific to 2.0 architecture, but because teams treat a theme migration as licence to "tidy up" unrelated things at the same time. Keep these five untouched:

• URL slugs - leave every product, collection, page and article slug alone. A theme migration is not a URL restructure; combining the two makes it impossible to isolate which change caused a ranking movement.
• Existing redirects - carry the full URL redirect list into the new theme unchanged. Redirects protect equity from previous migrations; dropping them re-opens old 404s.
• Canonical strategy - keep the same rules for variants, filters, and pagination as covered in our canonical tags article. 2.0 doesn't require a different canonical approach.
• robots.txt.liquid customisations - copy them verbatim into the new theme; see our robots.txt guide for what merchants typically customise.
• Sitemap submission workflow - don't resubmit sitemaps unless the URL set actually changed. A theme change alone shouldn't trigger a sitemap resubmission.

The common thread across all five is scope discipline. A 1.0 to 2.0 migration is a rendering-layer change, not a content or information-architecture change, and treating it that way keeps the post-launch diagnosis simple: if traffic moves, you know it was the theme swap, not an unrelated slug rename or redirect cleanup running in parallel. Save those separate improvements for their own project, sequenced after the migration has settled and Search Console shows a stable crawl and index pattern for at least two to three weeks.

Version detector

If you're not sure whether a store - yours or a competitor's - is running on Online Store 1.0 or 2.0, use the tool below or the manual DevTools check underneath it.

fetch('/?section_id=header', { headers: { Accept: 'application/json' } })
  .then(r => console.log(r.status === 200 ? 'Likely 2.0' : '1.0 or non-Shopify'))

Frequently asked questions