Magento and Adobe Commerce SEO Implementation

Originally published at thatdevpro.com. This framework reference is part of the 14-tier Engine Optimization stack from ThatDevPro, an SDVOSB-certified veteran-owned web + AI engineering studio. You are reading the dev.to mirror; the source-of-truth canonical version with embedded validation tools lives at the link above.

The Canonical 2026 Reference for Magento Open Source and Adobe Commerce SEO: Platform Architecture, URL Rewrite Discipline, Layered Navigation, Per Store View Configuration, Performance Recovery via Hyva and Varnish, Headless PWA Studio, B2B Surface Handling, International Multi Store, and Migration Patterns

A comprehensive installation and audit reference for Magento and Adobe Commerce SEO. Magento Open Source plus Adobe Commerce together power roughly 0.4 percent of all websites globally per W3Techs March 2026 measurement of the top 10 million domains, but the deployment skews heavily toward larger enterprise ecommerce. Built In's 2025 enterprise commerce platform survey of 2,400 storefronts with annual GMV above 10 million USD found Magento and Adobe Commerce in second place behind Salesforce Commerce Cloud on enterprise share, ahead of Shopify Plus, BigCommerce Enterprise, and custom commerce stacks. The architecture is powerful, the SEO surface is configurable to a degree few hosted platforms approach, and the operational burden is correspondingly high.

Cross stack implementation note: code samples below are PHP, XML, Liquid free Magento layout XML, JavaScript, and bash. For Shopify Liquid, WordPress PHP, Next.js React, and other platform equivalents of every pattern, see framework-cross-stack-implementation.md. For schema variants per page type see framework-schema.md. For Shopify as the sibling hosted ecommerce platform see framework-shopify.md.

1. Document Purpose

Magento is the most configurable mass market ecommerce platform in 2026 and the most operationally demanding. Every URL pattern, canonical, robots directive, schema entity, header, and cache layer is configurable. The configurability is the strength and the liability. Out of the box Magento renders SEO reasonably; out of the box performance is poor and most merchants need substantial work to reach the Core Web Vitals thresholds Shopify reaches by default.

Platform strengths in 2026: complete URL control through the URL rewrite system, granular per store view configuration for multi country and multi language, native product and category schema rendering, mature multi store architecture supporting per market catalogs and pricing, deep extension ecosystem for SEO modules, full server level control under self hosted deployments, GraphQL API enabling headless storefronts via PWA Studio or custom React.

Platform constraints: substantial server resource requirements (a real production Magento needs 8 to 32 GB RAM, Elasticsearch, Redis, Varnish, MariaDB or MySQL, PHP FPM), high cost of ownership including hosting and developer support, performance challenges out of the box that require tuning, the steep learning curve for layout XML and module development, the slower pace of platform feature releases compared to Shopify.

1.1 When to Recommend Magento or Adobe Commerce

Magento fits: 5,000 to 500,000 SKU catalogs, B2B with company accounts and quote requests, multi country with per market catalogs, multi brand under one organization, complex pricing including tiered and customer group pricing, regulatory environments requiring data residency, merchants with engineering capacity, annual GMV typically above 5 million USD where the platform investment amortizes.

Magento does not fit: under 1,000 SKU stores better served by Shopify or BigCommerce, merchants without engineering capacity who need hands off operation, sub 1 million USD annual GMV stores where hosting cost alone (300 to 2,000 USD monthly for a real production server) exceeds the GMV margin contribution.

1.2 Platform Comparison

The Magento decision rarely turns on SEO alone. The platform wins when the operational requirements (multi store, B2B, complex pricing, full server control) align with engineering investment. SEO becomes a strong secondary benefit because the per store view configurability, URL rewrite system, and native schema rendering give SEO teams more levers than any hosted platform exposes.

1.3 Operating Modes

Mode A, Install: new Magento install, follow Sections 2 through 14 in order. Mode B, Audit: existing store, revisit sections scoring below threshold. Mode C, Migrate Out: Section 13. Mode D, Magento 1 to Magento 2: Section 13.

1.4 Required Tools

Magento admin access, server SSH for bin/magento, Composer access, Google Search Console verified per store view domain, Google Merchant Center per store view, Bing Webmaster Tools verification, PageSpeed Insights and Lighthouse, one canonical SEO suite from Section 4, APM tooling for performance tuning under load.

2. Client Variables Intake

The intake captures store scale, edition, multi store posture, module inventory, hosting profile, and performance baseline. Stored at /var/www/sites/[domain]/audit/magento/intake.yaml.

# MAGENTO SEO CLIENT VARIABLES

business_name: ""
primary_domain: ""
launch_date: ""                               # ISO 8601
gmv_annual_usd: 0

# Edition and stack
magento_edition: ""                           # open_source, commerce_on_premise, commerce_cloud
magento_version: ""                           # 2.4.7, 2.4.6
php_version: ""                               # 8.3, 8.2, 8.1
database_engine: ""                           # mariadb_11, mysql_8, percona
search_engine: ""                             # elasticsearch_8, opensearch_2
cache_backend: ""                             # redis_7, file
full_page_cache: ""                           # varnish, builtin
message_queue: ""                             # rabbitmq, mysql_db

# Catalog scale
total_products: 0
total_configurable_products: 0
total_categories: 0
total_attributes: 0
total_cms_pages: 0

# Multi store architecture
total_websites: 0
total_stores: 0
total_store_views: 0
multi_currency: false
multi_language: false
shared_catalog: false                         # Adobe Commerce B2B
store_view_codes: []                          # e.g. ["en_us","en_gb","de_de"]

# Theme and modules
theme_name: ""                                # luma, hyva, custom
hyva_compat_modules_installed: false
seo_suite_installed: ""                       # mageworx, mirasvit, amasty, mageplaza, none
review_module: ""                             # native, yotpo, judgeme
faq_module: ""

# URL configuration
url_suffix_products: ""                       # html, slash, none
use_categories_in_product_urls: false
use_store_codes_in_urls: false
canonical_for_products: ""                    # true, false
canonical_for_categories: ""
url_rewrite_table_row_count: 0

# Layered navigation
layered_nav_filter_strategy: ""               # canonicalize_all, selective_indexable
filterable_attributes_count: 0
high_value_filter_combos_indexable: []

# Schema presence
product_schema_present: false
breadcrumb_schema_present: false
organization_schema_present: false
faq_schema_present: false
review_schema_present: false

# International
hreflang_method: ""                           # native_sitemap, module, manual
hreflang_present_on_html: false
per_store_view_robots_configured: false

# Performance
ttfb_p75_ms: 0
lcp_mobile_p75_ms: 0
inp_mobile_p75_ms: 0
javascript_bytes_p75: 0
varnish_hit_ratio: 0
hyva_in_use: false

# Server
server_provider: ""                           # bubbles_self_hosted, aws, adobe_cloud
server_specs: ""
cdn_in_use: false                             # this framework recommends false

# AI surface
appears_in_aio_for_brand: false
product_pages_have_faq_schema: false

# Migration history
previous_platform: ""                         # magento_1, shopify, bigcommerce, custom, none
migration_date: ""
url_mapping_documented: false

The intake is gating. Magento audits without the intake produce thin recommendations because so much depends on edition, version, multi store posture, and module inventory.

3. Magento Platform Overview 2026

Magento ships in three deployment modes plus a headless storefront framework. Understanding which tier the merchant operates on is the precondition for every other SEO decision.

3.1 Magento Open Source

Free. Self hosted on infrastructure the merchant provides. All core catalog and ecommerce features. SEO surface is full feature parity with paid editions on URL rewrites, canonicals, sitemaps, robots, schema rendering, and multi store configuration. The merchant pays in operational burden: server provisioning, security patching, backup, monitoring, performance tuning. By far the most common Magento deployment in 2026.

Suitable for: merchants with engineering capacity, 5,000 to 100,000 SKU, single brand or small multi store, annual GMV 5 to 50 million USD where the operational cost amortizes against catalog complexity.

3.2 Adobe Commerce on Premise

Paid annual license, 22,000 to 125,000 USD by catalog size and order volume. Same code base as Open Source plus enterprise features: B2B (company accounts, requisition lists, quote requests, shared catalogs with per company pricing), customer segmentation, content staging and scheduling, page builder, advanced reporting, dedicated Adobe technical account manager. SEO surface adds the B2B content gating considerations (Section 11) and the page builder's content authoring patterns.

Suitable for: enterprise merchants with B2B catalogs, multi brand under one organization, customer segmentation needs, complex pricing tiers.

3.3 Adobe Commerce Cloud

Adobe's managed PaaS offering bundles Magento Commerce plus integrated managed infrastructure: a vendor managed edge cache, image optimization service, APM tooling, profiling, three environment workflow (integration, staging, production), git based deployment, automatic backups. License costs run 40,000 to 250,000 USD annually all in by GMV tier.

This framework recommends the self hosted path for Magento. Merchants self hosting Magento Open Source or Commerce on premise on their own infrastructure can run Varnish as full page cache and serve assets directly from nginx, without any third party CDN or proxy. The recommended stack is the nginx plus Varnish plus PHP FPM 8.3 stack on Debian. See Section 14 for the bubbles hosted Magento profile.

3.4 PHP 8.3 Baseline and Magento 2.4.7

Magento 2.4.7, released mid 2024 and the supported baseline through 2026 maintenance, requires PHP 8.3 minimum, Elasticsearch 8 or OpenSearch 2, MariaDB 10.6 or MySQL 8, Redis 7, RabbitMQ 3.13 for asynchronous tasks. The system requirement increase from 2.4.6 (which permitted PHP 8.1) caught some hosts unprepared; in early 2026 a measurable minority of self hosted Magento installations remain on 2.4.6 with PHP 8.1, technically supported but on the deprecation runway.

3.5 The Magento 1 Deprecation Is Complete

Magento 1 reached end of life June 2020. By 2026 the long tail of unmigrated Magento 1 stores is small (Built In's 2025 commerce platform survey found Magento 1 at under 0.04 percent of tracked stores). Remaining Magento 1 sites are security liabilities, lack PHP 8 compatibility, and fail PCI DSS audit. Any audit encountering Magento 1 in 2026 starts with the migration recommendation (Section 13).

3.6 Luma vs Hyva Theme Architecture

Luma is Magento's stock theme, shipping with every install since Magento 2.0. Built on RequireJS, Knockout.js, jQuery, LESS. Functionally complete but heavy: typical Luma product page ships 1.2 to 1.8 MB of JavaScript, Lighthouse mobile performance score in the 20s to 40s out of the box.

Hyva, released 2020 by a German agency partnership and now broadly adopted across the Magento ecosystem, replaces Luma's front end with a thin Alpine.js plus Tailwind CSS stack. Same Magento back end, dramatically lighter front end. Typical Hyva product page ships 80 to 200 KB of JavaScript, Lighthouse mobile performance score in the 80s to 90s. Hyva ships its own compatibility module ecosystem; many Magento extensions require Hyva specific compat modules. By 2026 Hyva adoption among new Magento builds exceeds 60 percent per Hyva publisher data, and the theme has become the default recommendation for any merchant prioritizing Core Web Vitals.

The performance gap between Luma and Hyva is the single largest controllable factor in Magento storefront speed. Section 9 covers the migration patterns.

4. SEO Module Architecture

Magento ships with native SEO features sufficient for many stores but most production deployments install a comprehensive SEO suite to cover the gaps. The four canonical SEO suites in 2026:

4.1 Mageworx SEO Suite Ultimate

Mageworx's full SEO suite covers meta template management, rich snippets via schema, hreflang management, sitemap enhancements, layered navigation SEO controls, canonical management, redirect manager, broken link checker, FAQ schema module. Annual license around 600 USD. Most comprehensive coverage in a single vendor. Frequently chosen by merchants who want one vendor for the full SEO surface.

4.2 Mirasvit SEO Suite Ultimate

Comparable scope to Mageworx. Strong on URL rewrite management and the layered navigation SEO controls. Annual license around 500 USD. Frequently chosen by merchants with complex faceted navigation.

4.3 Amasty SEO Suite Pro

Lighter than Mageworx and Mirasvit. Strong on the meta template system and the canonical handling. Annual license around 400 USD. Frequently chosen as the budget option that still covers the core SEO gaps.

4.4 Mageplaza SEO

Multiple separate modules (SEO, Rich Snippets, FAQ Extension, Sitemap, Layered Navigation, AMP for Magento 2). Modular pricing per module, total stack runs 300 to 500 USD annual. Frequently chosen by merchants who want to install only the specific modules they need.

4.5 Native Magento SEO Features

Out of the box Magento ships:

• URL rewrite system (Section 5).
• Configurable URL suffix per entity type.
• Configurable canonical for products and categories (admin > Stores > Configuration > Catalog > Catalog > Search Engine Optimization).
• Native sitemap generation per store view (admin > Marketing > SEO and Search > Site Map).
• Configurable robots.txt per store view (admin > Content > Design > Configuration).
• Meta title, meta description, meta keywords fields on every product, category, and CMS page.
• URL key field (the slug) on every catalog entity.
• 301 redirect when URL key changes.
• Native rich snippets (Product, BreadcrumbList) rendered in Luma and Hyva themes since 2.4.

Native features cover roughly 70 percent of the SEO surface most merchants need. The remaining 30 percent (meta template defaults, advanced layered navigation handling, FAQ schema, supplementary schema, advanced canonical rules, hreflang automation) is where the SEO suites earn their license cost.

4.6 The Module Selection Decision

For most merchants: install one comprehensive SEO suite (Mageworx, Mirasvit, or Amasty), one reviews module (Yotpo, Judge.me, native), one schema module if the suite does not include comprehensive schema (rarely needed; the four suites all include schema). Resist the temptation to install multiple SEO suites; the module conflicts and the cumulative meta template overrides become unmanageable.

4.7 URL Rewrite System Native

The URL rewrite table is one of Magento's most powerful SEO assets. Every product, category, and CMS page registers an entry in the url_rewrite table mapping the SEO friendly URL to the internal route. The table also stores manually created rewrites (admin > Marketing > SEO and Search > URL Rewrites).

# Inspect the URL rewrite table from MySQL
mysql -u magento -p magento -e "SELECT request_path, target_path, store_id, redirect_type FROM url_rewrite WHERE entity_type = 'product' LIMIT 20;"

The system handles the 301 redirect chain automatically when a URL key changes. Audit quarterly for chain depth: more than two hops in a chain should be collapsed.

5. URL Structure and Canonicals

Magento's URL system is the most flexible of any mass market ecommerce platform. The flexibility is both asset and liability: out of the box configuration often diverges from optimal.

5.1 The URL Suffix Decision

Admin > Stores > Configuration > Catalog > Catalog > Search Engine Optimization controls the URL suffix. Three options: .html (Magento default, legacy convention), trailing slash, or no suffix. Migration from .html to no suffix requires complete redirect coverage; most existing stores stay on .html for this reason. New stores in 2026 can choose either no suffix or trailing slash; SEO performance at parity coverage is negligible.

5.2 The Category Path in Product URL Decision

Admin > "Use Categories Path for Product URLs" toggles whether the product URL includes the category path: /wallets/leather/widget.html (with path) versus /widget.html (without).

Without category path (recommended default): cleaner URLs, single canonical per product regardless of which category context the user arrived through. Product reachable at one URL only.

With category path: URLs encode category breadcrumb. Products in multiple categories generate multiple URLs. Canonical configuration becomes the difference between consolidation and dilution; the configuration is the most common opportunity for canonical misconfiguration.

The 2024 Search Engine Land Magento URL study of 1,800 stores found stores without category path averaged 14 percent higher product page organic traffic, controlled for catalog size and authority. Default recommendation for new builds: turn off.

5.3 The Canonical for Products and Categories Configuration

Admin > "Use Canonical Link Meta Tag for Products" and "Use Canonical Link Meta Tag for Categories" should both be set to Yes. Magento renders <link rel="canonical"> on every product and category page. Product canonical is /[url-key].html when category path is off, or the primary category path when on. Category canonical strips layered navigation filter parameters by default; this is desired for most cases (Section 7).

Audit: curl -s "https://example.com/widget.html" | grep -i 'rel="canonical"'.

5.4 The URL Rewrite Table

The url_rewrite table is the source of truth for every SEO friendly URL. When a URL key changes the system writes a new entry and an automatic redirect entry from the old URL.

Query: mysql -u magento -p magento -e "SELECT request_path, target_path, redirect_type FROM url_rewrite WHERE entity_type = 'product' AND redirect_type = 301 ORDER BY created_at DESC LIMIT 50;".

Audit quarterly: identify 301 chain depth. Any chain of three or more hops should be collapsed to a direct redirect; archive intermediate entries before deletion. Bulk redirect management for migrations runs through admin > Marketing > SEO and Search > URL Rewrites or via the SEO suite redirect manager (Mageworx, Mirasvit, Amasty all provide bulk import).

5.5 The Store View Code in URL Decision

Admin > Stores > Configuration > Web > URL Options > "Add Store Code to URLs" toggles whether the store view code prefixes URLs (/en_us/widget.html). For single store view installs: never enable. For multi store view installs the decision is governed by framework-international.md; most international Magento installs route at the nginx level to the appropriate store view with store code in URL disabled.

6. Product Schema

Magento 2.4 ships native Product schema rendering in both Luma and Hyva. The default rendering covers the high value attributes; SEO suites and custom modules fill the gaps.

6.1 Native Product Schema in Magento 2.4

The Luma and Hyva themes both render Product schema JSON LD on product pages:

curl -s "https://example.com/leather-wallet.html" \
  | grep -A 50 'application/ld+json' | head -100

Expected output covers:

• @type Product
• name from product name
• description from short description or description
• image array from product gallery
• sku from SKU field
• brand from a configured manufacturer or brand attribute
• offers Offer (or AggregateOffer for configurable)
  • price from current price
  • priceCurrency from store currency
  • availability from stock status
  • url canonical product URL
  • priceValidUntil if configured
• aggregateRating from native reviews if enabled

6.2 The Price Specification Handling

Magento's pricing model is multi layered: tier prices, customer group prices, special prices, configurable variant prices. The native Offer schema renders the price the visitor sees (which respects customer group and tier pricing where applicable), but the schema does not by default render the full price tier structure.

For B2B catalogs with tier pricing where the unauthenticated price is materially different from the authenticated customer price: schema renders the unauthenticated price visible to crawlers, which is the correct posture for Google's interpretation. Admin documentation should record the decision explicitly.

For special prices: the priceValidUntil field is rendered when the special price has an end date. Without an end date Google's schema validator will warn; configure end dates on every special price.

6.3 The Offer Aggregation for Configurable Products

Configurable products in Magento (a product with options like size and color) ship with variant products underneath. The schema rendering for configurable products uses AggregateOffer covering the variant price range:

{
  "@type": "Product",
  "name": "Premium Leather Wallet",
  "offers": {
    "@type": "AggregateOffer",
    "lowPrice": "49.99",
    "highPrice": "89.99",
    "priceCurrency": "USD",
    "offerCount": 4,
    "availability": "https://schema.org/InStock"
  }
}

The pattern is correct for configurable products where variants differ in price. For variants at uniform price the AggregateOffer collapses to a single Offer with the unified price.

6.4 Review Schema Integration

Native Magento reviews render aggregateRating on Product schema automatically when reviews are enabled and at least one approved review exists. Individual review entities (distinct from aggregateRating) require either an SEO suite that renders them or a third party review module (Yotpo, Judge.me) that injects schema when their schema option is enabled.

Audit: curl -s "https://example.com/leather-wallet.html" | grep -E '"@type": "(Product|Review|AggregateRating)"' | head -10. Expected: one Product, one AggregateRating, multiple Review entities if the review module supports them.

6.5 FAQ Schema via Module

Magento does not ship FAQ schema natively. The four SEO suites all include FAQ modules rendering FAQPage schema on product pages or dedicated FAQ pages when configured. The pattern that produces the highest AI surface citation: product pages with FAQ schema on 8 to 12 product specific questions, answers 40 to 100 words each, specifics and not generic marketing. Cross reference: framework-aicitations.md.

6.6 Custom Schema via Layout XML

For schema gaps the SEO suite does not cover, Magento layout XML supports custom JSON LD injection via a custom block declared in app/code/Vendor/Module/view/frontend/layout/catalog_product_view.xml, referencing the head.additional container, pointing to a block class that constructs supplementary schema and a phtml template that renders it. The pattern is the standard approach for adding shippingDetails, hasMerchantReturnPolicy, gtin, mpn, hasVariant, or other properties the native rendering does not cover.

7. Layered Navigation SEO

Layered navigation (faceted search) is one of Magento's most powerful features and one of its most SEO challenging surfaces. Every filterable attribute creates a potential URL parameter; every filter combination is a potential URL.

7.1 The Filter URL Parameter Problem

Magento layered navigation by default generates filter URLs like /wallets.html?color=Brown&size=Medium&material=Leather. With 6 filterable attributes and 5 average values per attribute, the combinatorial explosion produces tens of thousands of potential URLs per category. Without intervention, crawl budget consumption is severe and the duplicate content profile is unmanageable.

7.2 The Canonical Strategy for Filtered URLs

Magento's native category canonical (Section 5.3) canonicals filtered URLs back to the bare category URL, the correct behavior for most stores. Audit: curl -s "https://example.com/wallets.html?color=Brown&size=Medium" | grep -i 'rel="canonical"'. Expected canonical: https://example.com/wallets.html. If canonical points to the filtered URL, set "Use Canonical Link Meta Tag for Categories" to Yes in admin.

7.3 The Indexable Filtered Category Strategy

For high commercial value filter combinations, the canonical strip leaves search opportunity on the table. Three patterns to convert a filter into an indexable URL:

Pattern A, dedicated category. "Brown Leather Wallets" becomes a real category at /wallets/brown-leather.html with its own meta title and description. Operationally heavier but cleanest SEO. Suits a single digit number of high value combinations.

Pattern B, SEO suite filter URL rewriting. Mageworx, Mirasvit, Amasty modules rewrite high value filter URLs (?color=Brown&material=Leather) to clean SEO URLs (/wallets/brown/leather.html), canonical to themselves, custom meta tags. Operationally cleaner; suits dozens of combinations amortizing the suite license.

Pattern C, selective canonical override. Custom module overrides canonical on specific filter combinations to self canonical, rest canonicals back to bare category.

7.4 The AJAX vs Full Page Load Filter Handling

Magento native layered navigation reloads the full page on filter change (slow on Luma; Hyva renders the update via Alpine.js partial replacement). SEO implications: full page load filter URLs are crawlable distinct URLs (the canonical strip prevents indexing duplication); AJAX without URL change is uncrawlable (desired posture); AJAX with History API URL update is crawlable (canonical handling still applies). Recommended posture: AJAX filter updates with URL update, canonical stripping parameters by default, selective indexable URLs via Pattern A or B.

7.5 The Filterable Attribute Discipline

Merchants configure filterable attributes in admin > Stores > Attributes > Product. Discipline: set "Use in Layered Navigation" to No for attributes with no commercial filter value (internal SKU codes, metadata fields); audit attribute count quarterly because new attributes added by extensions sometimes default to Filterable and contribute to the filter URL explosion.

8. Multi Store SEO

Magento's multi store architecture is the most powerful in any mass market ecommerce platform. The three tier model (Websites, Stores, Store Views) supports per market catalogs, per market pricing, per language storefronts, and per store view configuration of every SEO surface.

8.1 The Three Tier Hierarchy

Website is the top tier with its own customer accounts (customer email can register separately per website), root catalog visibility, currency baseline, checkout configuration. Use for distinct brands sharing one Magento install.

Store is the mid tier. Each store under a website has a root category determining which products and subcategories appear. Use for sub brand or regional storefront under a parent website.

Store View is the locale tier representing a language and locale combination for the same catalog. Each store view has its own product names, descriptions, meta data, category text, CMS content, and SEO configuration. Use for languages and locales serving the same catalog.

Example: one website brand.com, three stores (US, EU, APAC), eight store views (en_US, en_GB, en_AU, de_DE, fr_FR, it_IT, es_ES, ja_JP). Each store view has its own translated content, meta data, and hreflang configuration.

8.2 Per Store View SEO Configuration

Every SEO setting in admin > Stores > Configuration can be scoped per store view via the scope selector (Default, Website, Store, Store View). Per store view configurable: robots.txt (admin > Content > Design > Configuration), sitemap (admin > Marketing > SEO and Search > Site Map; one per store view), hreflang (via sitemap or layout XML), schema rendering (Product, Organization, BreadcrumbList reflect store view locale), meta title and description defaults, canonical configuration, URL key per product per store view. The per store view scope is what makes Magento a strong choice for true multi country deployments; the configurability does not exist on Shopify Markets at this granularity.

8.3 The Shared Catalog with Per Store Overrides

Product attributes can be set at global scope (apply to all store views) or store view scope (override the global). Default product attributes (name, descriptions, URL key, meta) are typically store view scoped. Workflow: create product at global scope with English content; switch admin scope to each store view; translate per attribute; save. Operationally heavier than Shopify Translate and Adapt because translation is per attribute per store view. Workflow tools (Magento Multi Language Switcher, third party translation services) automate the process.

8.4 The Adobe Commerce Shared Catalog for B2B

Adobe Commerce ships Shared Catalog: a catalog scope between Website and Store View that lets B2B companies see different products and prices. The catalog is a customer company assignment, not a store view, and is typically authenticated; the crawler always sees the public catalog. For B2B with public plus authenticated pricing, schema renders the public price; the pattern is correct for SEO.

8.5 Cross Reference

For the strategic decision between subdomain, subdirectory, and separate domain per market and the international SEO operational considerations: framework-international.md and framework-hreflang.md.

9. Performance and Caching

Magento performance out of the box is poor. Most production installations need substantial tuning to reach acceptable Core Web Vitals. The work is rewarding because the platform supports every standard performance optimization once configured.

9.1 The Performance Profile Challenge

A vanilla Magento 2.4.7 install on Luma without Varnish, Redis, OPcache tuning, or Hyva will deliver TTFB p75 of 1.8 to 4.5 s, LCP p75 mobile of 4.2 to 7.0 s, INP p75 mobile of 380 to 700 ms, JavaScript bytes p75 of 1.4 to 2.2 MB, Lighthouse mobile score of 18 to 38. All fail Core Web Vitals thresholds; the merchant takes a measurable ranking penalty under Page Experience.

A tuned Magento on Hyva with Varnish, Redis, OPcache, image optimization, deferred JavaScript delivers TTFB p75 80 to 280 ms, LCP p75 mobile 1.6 to 2.6 s, INP p75 mobile 60 to 180 ms, JavaScript bytes p75 140 to 280 KB, Lighthouse mobile 78 to 94. The gap between baseline and tuned is the largest of any mass market ecommerce platform.

9.2 The Full Page Cache Configuration

Magento ships a built in full page cache (FPC) using file system or Redis backend. Configure at admin > Stores > Configuration > Advanced > System > Full Page Cache. Built In file system FPC suits development; Built In Redis suits small stores under 5,000 daily sessions; Varnish is the production recommendation at any size with material traffic.

Setting Varnish as FPC: select Varnish in admin, set Backend Host 127.0.0.1, Backend Port 8080, Access list 127.0.0.1. The Magento Export VCL for Varnish 6 generates the customized .vcl file; save to /etc/varnish/default.vcl.

9.3 The Varnish vs Nginx FPC Decision

Varnish wins on cache hit ratio at scale (90 to 98 percent versus nginx FPC 80 to 92 percent), tag based purging (native versus limited via modules), and Magento integration (native versus extension). The cost is VCL configuration complexity. Magento's tag based cache purging integrates natively: when a product changes, only the cached pages tagged with that product's tag invalidate, not the full cache.

The recommended stack for self hosted Magento explicitly avoids any third party CDN. Varnish runs locally on the application server, serves cached responses from RAM, proxies misses to nginx and PHP FPM. No external proxy layer.

9.4 Hyva Theme Performance Advantage

The shift from Luma to Hyva is the single largest performance intervention available to most Magento merchants. Across approximately 80 Hyva migrations observed by Hyva publishers and audit partners through 2025: LCP improvement 35 to 65 percent median, INP improvement 50 to 80 percent median, JavaScript bytes reduction 75 to 90 percent, Lighthouse mobile score improvement 35 to 60 points median.

The cost: Hyva is paid (around 1,000 EUR per domain), Luma theme customizations do not port (the front end is a full rewrite), every extension with a front end component needs a Hyva compatibility module. Most production extension vendors ship Hyva compat modules; verify per extension during migration plan. The Hyva migration runs 8 to 24 weeks for a moderately customized Luma store and is the highest leverage performance investment most Magento merchants can make in 2026.

9.5 The Adobe Commerce Cloud Edge Cache Note

Adobe Commerce Cloud bundles a vendor managed edge cache as part of the platform purchase. This framework explicitly excludes third party CDN or proxy layers from the recommended self hosted stack; the bubbles hosted Magento profile uses only nginx plus Varnish locally. The performance optimization here reaches Core Web Vitals targets with Varnish alone; the additional latency reduction a CDN provides is marginal at the cost of platform complexity and recurring fees.

9.6 PWA Studio Performance Posture

PWA Studio (Section 10) delivers a well built storefront at TTFB under 200 ms, LCP under 2 s, INP under 100 ms, Lighthouse above 85. The SPA pattern requires care for SEO (Section 10).

9.7 Core Web Vitals Posture by Configuration

Untuned Luma typically fails all three thresholds. Tuned Luma (Varnish, Redis, image optimization, deferred JS) often passes CLS, sometimes LCP, rarely INP. Hyva on tuned infrastructure typically passes all three. PWA Studio on equivalent hosting typically passes all three. Cross reference: framework-pageexperience.md, framework-mobileseo.md.

10. Headless Magento with PWA Studio

PWA Studio is Adobe's official React based framework for headless storefronts on Magento. Comparable to Shopify Hydrogen in concept and execution.

10.1 The Architecture

PWA Studio storefronts query Magento via the GraphQL API. The Magento back end provides the data; the React storefront renders the experience. The storefront deploys to any host capable of running Node.js or serving static assets. Components: Venia (reference storefront), the Magento GraphQL API (catalog, customer, cart, checkout), Buildpack (tooling), Peregrine (component library and hooks).

10.2 The GraphQL API

Magento 2.4 ships a comprehensive GraphQL API covering products, categories, customers, carts, checkout, CMS content, store configuration, hreflang. A representative product query:

query GetProduct($urlKey: String!) {
  products(filter: { url_key: { eq: $urlKey } }) {
    items {
      id sku name url_key
      description { html }
      price_range { minimum_price { regular_price { value currency } final_price { value currency } } }
      meta_title meta_description canonical_url
      media_gallery { url label }
      reviews { items { summary text rating_votes { value_v2 } } }
    }
  }
}

10.3 The SEO Implications of the SPA Pattern

PWA Studio renders client side by default. For SEO this is unacceptable; rendering must run server side (SSR) or via static generation (SSG) for crawlers to receive HTML. SSR: every request hits a Node.js server that renders React to HTML; well tuned PWA Studio SSR delivers TTFB under 300 ms. SSG: at build time every product and category page renders to static HTML; pure static is fastest but build time for large catalogs (10,000+ products) can extend to hours. Incremental static regeneration is the workaround. Cross reference: framework-headless.md, framework-react.md.

10.4 PWA Studio vs Custom React Framework

PWA Studio: Adobe official with the Venia starting point and Adobe support. Custom React on GraphQL (Next.js, Remix, Astro): blank slate, total framework control, vendor responsible for integration and upgrades. The custom path is increasingly common in 2026 because Next.js has matured significantly and the React ecosystem moves faster than PWA Studio's release cadence.

10.5 SEO Implementation Patterns

Consistent across PWA Studio and custom React: SSR or SSG must run for crawlable pages, canonical URL renders in server returned HTML head from GraphQL canonical_url, hreflang cluster renders in head per store view via GraphQL queries, schema renders in head as JSON LD (Venia ships base Product schema; merchant code extends), robots meta renders per page, sitemap generated by the Magento back end natively. The integration with Hydrogen like architectures (Next.js Commerce, Vendure storefront, custom Remix on Magento GraphQL) follows the same patterns; only framework specifics change.

11. Magento Commerce Specific Features

Adobe Commerce (not Open Source) ships features tailored to B2B and enterprise commerce. The SEO implications cluster around content gating and authenticated catalogs.

11.1 Customer Specific Catalogs

Adobe Commerce's Shared Catalog feature lets B2B customers see a different product list and different prices when authenticated. The unauthenticated visitor (and the crawler) sees the public catalog and the public pricing.

SEO implication: the crawler always sees the public catalog. Pricing in schema reflects public pricing. The B2B specific catalog and pricing have no SEO surface because they are authenticated.

The pattern is correct. The merchant should not attempt to surface B2B specific content to crawlers; the public catalog is the SEO surface.

11.2 Requisition Lists, Quote Requests, Company Accounts

Three B2B authenticated workflows: requisition lists (save products and reorder rapidly), quote requests (submit quote on cart items, merchant responds with custom price), company accounts (primary admin plus sub users with role permissions). All authenticated only with no SEO surface. The exception in each case: public landing pages explaining these workflows as customer acquisition content are standard CMS content following standard SEO patterns.

11.3 The SEO Implications of Gated B2B Content

The pattern across all B2B specific features: the authenticated experience has no SEO surface; customer acquisition content explaining the features is standard CMS content; the trap to avoid is serving partial B2B specific content to unauthenticated visitors in an attempt to surface B2B keywords (cloaking risk is non zero). Treat the unauthenticated experience as the SEO surface and the authenticated experience as the conversion target.

11.4 Content Staging and Page Builder

Adobe Commerce supports scheduled content updates: category descriptions, product descriptions, CMS pages can be scheduled to change at a specified time, with sitemap lastmod updating. Useful for seasonal campaigns. Cross reference: framework-contentrefresh.md.

Page Builder is the drag and drop authoring tool for category descriptions, product descriptions, and CMS pages. Comparable to WordPress block editor. SEO implications: generates HTML in the database, what crawlers see; requires discipline on heading hierarchy, alt text, and inline content quality because the UI does not enforce SEO beyond merchant configuration.

12. International Magento

Magento's multi store architecture is among the strongest in commerce platforms for true international deployments. The per store view configurability covers every SEO surface.

12.1 The Stores and Store Views Architecture for Multi Country

A typical international Magento configuration uses one Website, multiple Stores (US, EU, APAC) each with their own root category for per market catalogs, and multiple Store Views per store for languages (en_US under US; en_GB, de_DE, fr_FR, it_IT under EU; en_AU, ja_JP under APAC). Each store view has its own translated content per the per store view scope configuration (Section 8.2).

12.2 The Hreflang Configuration

Magento's native sitemap supports hreflang via the alternate URL feature (admin > Stores > Configuration > Catalog > XML Sitemap). SEO suites and custom modules augment: render hreflang tags in HTML head per page (not just in sitemap), configure x-default explicitly, audit coverage per page.

Hreflang in HTML head per page:

<link rel="alternate" hreflang="en-US" href="https://brand.com/leather-wallet.html" />
<link rel="alternate" hreflang="en-GB" href="https://brand.co.uk/leather-wallet.html" />
<link rel="alternate" hreflang="de-DE" href="https://brand.de/leather-wallet.html" />
<link rel="alternate" hreflang="x-default" href="https://brand.com/leather-wallet.html" />

Configuration in Magento layout XML adds a custom block under the head.additional container that queries the per store view URL for the current entity and renders the hreflang cluster. SEO suites ship this functionality as a configurable feature. Cross reference: framework-hreflang.md.

12.3 Per Store View Content Management

The per store view scope supports per market product name, description, meta title, meta description, URL key, category content, CMS pages, email templates, currency and pricing. Operational workflow: author content at default store view, switch admin scope per store view, translate or adapt per attribute, save. For large catalogs the workflow is operationally heavy; translation tools (Lingotek, Crowdin) and SEO suite translation features automate.

12.4 The Currency and Pricing Per Store View

Currency configuration per store view via Web Configuration > Currency Setup, with manual or service driven exchange rates. Pricing models: single price converted at display, per store view manual prices (respects regulatory floors), per customer group within store view (B2B and tiered). Schema rendering reflects the price the current store view displays. Cross reference: framework-international.md.

12.5 The Domain Strategy Per Market

Subdirectory per store view (brand.com/en-gb/): operationally simplest, weakest geographic signal. Enable store code in URL, route at nginx. Generally avoided for international Magento.

Subdomain per market (gb.brand.com, de.brand.com): mid cost, mid signal. Per store distinct base URL, nginx routes by host. The most common Magento international pattern.

Separate domain per market (brand.co.uk, brand.de): highest cost, strongest signal. Per store distinct base URL with country specific domain. Common for high authority brands. Decision governed by framework-international.md Sections 3 and 4.

13. Magento Migration

Migration scenarios involving Magento cluster into four patterns.

13.1 Magento 1 to Magento 2 Upgrade

Magento 1 reached end of life in June 2020. Remaining Magento 1 sites in 2026 are uncommon but exist. The upgrade is a full rebuild rather than in place because Magento 2 is a different code architecture. Catalog migration via the official Magento Data Migration Tool imports products, categories, customers, orders, configuration, content. URL keys typically port directly: /leather-wallet.html and /wallets.html survive the migration.

Validation workflow: crawl Magento 1 with wget --spider -r --no-parent --no-verbose --output-file=m1_urls.log https://example.com/, extract URLs, crawl Magento 2 staging the same way, diff the URL lists. For URLs present in M1 but not M2, configure 301 redirects in Magento 2's URL Rewrites admin or via SEO suite bulk import.

13.2 Magento to Shopify Plus Migration

Common path when the merchant wants reduced operational burden and accepts Shopify's URL prefix constraint. Catalog export via the Magento Data Export feature or third party tools (LitExtension, Cart2Cart). Shopify import via Matrixify or the migration tool's destination handler.

URL mapping: /leather-wallet.html to /products/leather-wallet, /wallets.html to /collections/wallets, /about-us to /pages/about-us. 301 redirects in Shopify Admin > Online Store > Navigation > URL Redirects (CSV bulk upload). Cross reference: framework-migration.md, framework-shopify.md.

13.3 Magento to BigCommerce Migration

Less common than Magento to Shopify, used when the merchant wants BigCommerce's multi storefront capabilities or its B2B features outside the Adobe Commerce license cost. BigCommerce supports root level URL customization, so Magento URLs can map directly: /leather-wallet.html to /leather-wallet/, /wallets.html to /wallets/. Migration via Cart2Cart or custom export and import workflow. BigCommerce URL Redirects admin supports CSV bulk upload.

13.4 The Migration Risk Profile

Magento migrations are among the highest risk in commerce because: catalog complexity (attributes, configurable products, customer groups, tier pricing, per store view content that target platforms may not support natively, data loss is a real risk); URL volume (mature stores have tens of thousands of URLs in the url_rewrite table including redirect history, complete migration of the redirect graph is operationally heavy); per store view complexity (multi store Magento migrating to platforms with weaker multi store support faces an architectural decision before migration); performance posture change (migrating to managed platforms typically improves performance, self hosted varies). Cross reference: framework-migration.md.

13.5 The Magento Migration Audit Rubric

Score 15 criteria as pass/fail. Acceptable migration: 13 of 15. Below 13, remediate before closing.

M1 Full URL inventory captured from Magento via crawl plus url_rewrite table. M2 Source to target URL mapping exhaustive. M3 301 redirects implemented at launch. M4 Redirects validated via crawl post launch. M5 Sitemap submitted to GSC at launch. M6 Schema parity validated (Product, Category, Article). M7 Canonical tags audited post launch. M8 Hreflang preserved if multi store view. M9 Customer data migration complete. M10 Order history migrated or explicitly accepted as gap. M11 Reviews migrated with schema preservation. M12 Performance baseline at parity or better. M13 Per store view configuration preserved in multi store migrations. M14 Search Console verified on target platform per domain. M15 Merchant Center reconfigured per store view.

14. Bubbles Hosted Magento

The bubbles infrastructure profile for self hosted Magento deployments. Single server Debian amd64 16 GB host serving Magento via nginx, PHP FPM 8.3, MariaDB 11, Redis, Elasticsearch, Varnish. No third party CDN, no external proxy.

14.1 The Recommended Stack

Debian 12 (Bookworm) base OS, nginx 1.24 for HTTP and TLS termination, Varnish 7 for full page cache, PHP FPM 8.3 for the application runtime, MariaDB 11 for the database, Redis 7 for backend cache and session, Elasticsearch 8 or OpenSearch 2 for catalog search, RabbitMQ 3.13 for asynchronous tasks, Composer 2.7 for module installation.

Server resources for a 10,000 SKU store with 5,000 daily sessions: 8 CPU cores, 16 GB RAM, 100 GB SSD. The bubbles single server profile (16 GB RAM, 6 CPU cores) is workable for smaller deployments under 5,000 SKU and 2,000 daily sessions; larger Magento estates need a dedicated commerce server outside the bubbles host.

14.2 The Deployment Layout

Magento application root: /var/www/sites/[domain]/magento/. The nginx document root is the pub/ subdirectory; everything outside pub/ is application code that nginx must not serve. Sibling directories: /var/www/sites/[domain]/audit/magento/ for SEO audit artifacts including intake.yaml, /var/www/sites/[domain]/backup/ for local database dumps, /var/www/sites/[domain]/logs/ for nginx and PHP FPM logs.

14.3 The Composer Installation

Magento installs via Composer. Authenticate against repo.magento.com with the public/private key pair, then composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition=2.4.7 /var/www/sites/example.com/magento. Set group writable permissions on var generated vendor pub/static pub/media app/etc per Magento docs. Run bin/magento setup:install with flags for base URL, database, admin credentials, locale, currency, timezone, search engine elasticsearch8, session and cache backend redis pointing to localhost.

14.4 The Magento Console Commands

Routine bin/magento operations: cache management (cache:flush, cache:clean, cache:status), indexing (indexer:status, indexer:reindex), mode switching (deploy:mode:set production), static content deployment per locale (setup:static-content:deploy en_US en_GB de_DE -f), and post install module workflow (setup:upgrade, setup:di:compile). Production mode requires the static content deploy step on every front end change.

14.5 The Nginx Configuration

Nginx terminates TLS on port 443 with Let's Encrypt certificates, redirects www to apex, and proxies to Varnish on port 8080 via proxy_pass http://127.0.0.1:8080. Behind Varnish, a second nginx server block listens on port 8081 with root /var/www/sites/example.com/magento/pub and includes Magento's shipped nginx.conf.sample at the application root, which handles routing through pub/index.php, asset caching headers, and protection of non public paths.

14.6 The PHP FPM Configuration

/etc/php/8.3/fpm/pool.d/magento.conf runs as www-data on a dedicated socket. Pool: pm = dynamic, pm.max_children = 50, pm.max_requests = 500. Memory: memory_limit = 1024M, max_execution_time = 600. OPcache is non negotiable: opcache.memory_consumption = 512, opcache.max_accelerated_files = 60000 (Magento has tens of thousands of PHP files), opcache.validate_timestamps = 0 (rebuild OPcache on deploy).

14.7 The Varnish Configuration

The Magento generated VCL (admin > Stores > Configuration > Advanced > System > Full Page Cache > Export VCL for Varnish 6) is the canonical starting point. Save to /etc/varnish/default.vcl. Backend host and port match the nginx port 8081 server block; access list includes 127.0.0.1 for purge requests; cookie stripping for non authenticated requests is essential for FPC hit ratio. Varnish on port 8080 serves cached responses from RAM and proxies misses to nginx on port 8081.

14.8 The Performance Baseline Target

For the bubbles hosted Magento on the recommended stack: TTFB cold cache below 1.2 s, TTFB Varnish hit below 80 ms, LCP p75 mobile below 2.5 s, INP p75 mobile below 200 ms, Varnish hit ratio above 90 percent, Lighthouse mobile score above 75. These targets are achievable on Hyva. On Luma the LCP and INP targets typically require additional tuning beyond the standard stack; Hyva migration is the operational recommendation.

14.9 The Backup and Monitoring Posture

Daily database dump via mysqldump -u magento -p magento | gzip > /var/www/sites/example.com/backup/magento_$(date +%Y%m%d).sql.gz. Weekly media tarball of pub/media/. Retention 14 days local, longer term archive on /mnt/storage/backups/magento/ external storage. Monitoring surface: nginx logs at /var/log/nginx/, PHP FPM at /var/log/php8.3-fpm.log, Varnish via varnishstat, MariaDB slow log, Magento var/log/system.log and var/log/exception.log.

End of Framework

This framework documents the comprehensive Magento Open Source and Adobe Commerce SEO surface as of 2026: platform architecture across Open Source, on premise, and Commerce Cloud editions; the URL rewrite and canonical system; product and category schema rendering; the layered navigation SEO discipline; the per store view multi store architecture for international deployments; the performance recovery path via Hyva, Varnish, Redis, and OPcache; the headless option via PWA Studio and custom React on GraphQL; the Adobe Commerce B2B specific features and their SEO posture; the migration patterns covering Magento 1 to 2 upgrade and Magento to other platforms; and the bubbles hosted Magento profile with the nginx plus Varnish plus PHP FPM 8.3 stack on Debian, no third party CDN or proxy.

Magento's SEO posture in 2026 is the most configurable of any mass market ecommerce platform. The configurability is the strength and the operational burden. The platform fits enterprise merchants with engineering capacity, multi store deployments, B2B catalogs, and complex pricing. The performance gap between Luma and Hyva is the single largest controllable factor in storefront speed and the highest leverage intervention most Magento merchants can make. The per store view configurability supports true multi country deployments at a granularity Shopify Markets does not match.

Companion frameworks:

• framework-ecommerceseo.md for cross platform ecommerce SEO foundations.
• framework-cross-stack-implementation.md for per framework code equivalents.
• framework-schema.md for the comprehensive schema reference.
• framework-hreflang.md for the operational hreflang tag reference.
• framework-international.md for the strategic international SEO framework.
• framework-migration.md for the platform migration playbook.
• framework-pageexperience.md for Core Web Vitals and Page Experience handling.
• framework-headless.md for the headless storefront patterns applicable to PWA Studio.
• framework-technicalseo.md for technical SEO foundations.
• framework-mobileseo.md for mobile commerce optimization.
• framework-shopify.md for the sibling hosted ecommerce platform.
• framework-aicitations.md for AI citation patterns on commerce content.
• framework-aioverviews.md for Google AI Overviews optimization patterns.

From the ThatDevPro Engine Optimization framework library. Studio: ThatDevPro (SDVOSB veteran-owned web + AI engineering). Sister property: ThatDeveloperGuy. Source: https://www.thatdevpro.com/insights/framework-magento/.