Honestly Discussing the Pros and Cons of Hydrogen + Oxygen: Why We Rebuilt Our Corporate Website with Hydrogen

The typical setup for headless commerce with Shopify is "Hydrogen + Oxygen." Hydrogen serves as the frontend development framework, and Oxygen provides the server (edge hosting) that delivers it.

While it's often said that "going headless makes things faster" or "gives you freedom," the reality is a bit more complex. This article aims to objectively organize the pros and cons of Hydrogen + Oxygen. Furthermore, it will touch upon often-overlooked security aspects and provide guidance on "which use cases it's suitable for." Finally, we will share what we prioritized when rebuilding our own corporate website (Flagship) with Hydrogen, leading to the release of the Hydrogen version in July 2026.

Benefits: Strengths of Hydrogen + Oxygen

1. Free URL Structure and Routing Design

The most distinct advantage is the flexibility of URL structure. With traditional Liquid themes, URLs were bound to fixed paths like /collections, /products, and /pages, meaning you couldn't remove prefixes such as /collections/.

In contrast, Hydrogen allows you to design any URL structure using React Router's (formerly Remix) nested routes and catch-all (splat) routes. You can freely replace /cart with /bag, or /collections with /categories, /brand, or any system of your own. This makes a significant difference when emphasizing site information architecture, brand experience, and URL consistency.

For example, if you want to create an event information section on your site. With Liquid, article URLs would inevitably include the /blogs/ prefix, like /blogs/events/hydrogen-seminar. With Hydrogen, you can make this /events/hydrogen-seminar, resulting in a clean URL without unnecessary strings. The ability to eliminate "system-mandated prefixes" like /blogs/ or /collections/ and design beautiful URLs that directly reflect the site's structure is a subtle yet powerful advantage. URLs, once published, are assets that are hard to change, impacting user clarity (being able to intuitively grasp the structure and meaning of a URL just by looking at it) and overall site consistency.

Here, a point of clarification is needed. Assigning URLs by language—for example, placing Japanese under / (no prefix) and English under /en/—is actually possible with Liquid themes using Shopify Markets (you can assign the primary language to the root and additional languages to subfolders). Our Hydrogen site also places Japanese at / and English at /en/, but this in itself is not a unique advantage of Hydrogen.

The essential strength of Hydrogen lies beyond that. It's not just about language assignment; it's the ability to fully design and control arbitrary path structures like /events, and the routing logic itself, yourselves. This means you can "design the URL system from scratch" rather than "configuring within the URL system provided by the system"—this is the fundamental difference from themes.

It's important to clarify that this isn't just about "visually appealing URLs." In today's smartphone-centric UI, users have fewer opportunities to directly see the URL itself, so the beauty of the URL shouldn't be overvalued as a superficial benefit. What's truly important is that the URL structure reflects the information architecture itself—how the site is constructed as a collection of information. For sites where presenting structured content is central, the ability to design "how information is structured" yourself is of great value. The freedom to control URLs is more than just the freedom to refine appearance; it's the freedom to design the very skeleton of your site (this perspective will be revisited later in "What use cases is it suitable for?").

Domestic Example: BONIQ (Sous Vide Machine Brand)

This freedom to "design the URL system from scratch" can be seen in existing Hydrogen sites within Japan. The official store of the sous vide machine brand BONIQ (boniq.store) is one of the few Japanese sites built with Shopify Hydrogen + Oxygen, and it utilizes a custom URL structure.

For instance, the following URLs could not be created with a Liquid theme:

• /about/philosophy, /about/recruit — Company information hierarchically organized under /about/. Liquid pages require /pages/ and cannot be nested this way.
• /journals/development/lowtemperature-cooking — Editorial content structured with 3 levels and a unique prefix /journals/. Liquid blogs are fixed to 2 levels (/blogs/{blog}/{article}), making this impossible.
• /support/faq, /support/warranty-policy — Support-related content grouped under /support/.

BONIQ organizes content according to its own information architecture, such as "journals," "stories," "about," and "support." This contrasts with Liquid, which forces everything into fixed categories like pages, blogs, collections, and products. Being able to freely design the frontend URL system while keeping the backend on Shopify is a clear value proposition of Hydrogen.

2. Ability to Create App-like Experiences

Page transitions are not full reloads, but rather app-like client-side transitions. By having complete control over the frontend rendering layer, you can meticulously craft every detail of the experience, including custom UIs, interactions, and 404 pages.

For example, our Hydrogen-based website incorporates rich effects such as 3D rendering (Three.js) and page-transition animations (GSAP). While not impossible with Liquid themes if you write scripts, Hydrogen, which allows direct use of the React ecosystem and modern frontend development environments (Vite, TypeScript, Tailwind, etc.), makes such intricate development significantly easier. The ability to develop with the mindset of "implementing to achieve the desired expression" rather than "adapting the expression to the theme's framework" is a major difference from Shopify theme-based production. It may not be an essential argument, but in areas like this, the developer experience with Hydrogen is significantly better than with Shopify themes.

3. Oxygen Hosting Available at No Additional Cost

From an economic standpoint, the fact that Oxygen hosting is included in the Shopify subscription fee is a significant advantage. According to Shopify's official documentation, "Oxygen is available at no additional cost with a paid Shopify plan," covering Basic, Shopify, Advanced, Plus, and Pause and Build plans (Starter plans and development stores are excluded).

There's no official mention of metered billing for data transfer (bandwidth) or request count, which means it's clearly more advantageous in terms of pure hosting costs compared to setups like Vercel or Netlify, which charge "hosting fees + data transfer." It also includes GitHub integration for CI/CD, preview deployments, and edge delivery, reducing the effort required for infrastructure setup and operation (note that GitHub-integrated deployments run on GitHub Actions, so their execution time is subject to GitHub's own usage quotas and pricing).

And beyond cost, an even greater advantage is the ability to leverage Shopify's powerful infrastructure directly. Oxygen runs on Shopify's global edge network, delivering content from locations close to users worldwide. This means you can piggyback on Shopify's foundation, which has handled massive traffic surges like Black Friday, at no additional cost, without having to expand your own servers or design scaling solutions. Automatic scaling during traffic spikes, protection against DDoS attacks, and stable delivery—these are things you would normally have to build and maintain with significant cost and expertise yourself, but with Oxygen, you can enjoy them as part of the Shopify platform, significantly lowering the barrier to headless commerce.

However, it's not truly "unlimited": there are limits on worker (bundle) size, CPU execution time, memory, and file uploads. That said, these are fixed technical limits defined as platform specifications — per-request, per-worker constraints — not metered quotas that incur charges or shrink as traffic grows. Under normal operation, increased traffic neither generates additional costs nor causes the site to break against these limits (although usage deemed abusive may be subject to throttling or other measures under the acceptable use policy).

4. Native Checkout and Extensions Remain Usable

Hydrogen hands off payment processing from the cart to Shopify's native hosted checkout. As a result, payment experiences like Shop Pay are maintained, and Checkout UI extensions function identically regardless of whether the frontend is Liquid or Hydrogen. Checkout is rendered in Shopify's execution environment, so it is unaffected by headless implementation.

The flip side is that even with Hydrogen, you cannot build the checkout screen itself as your own custom frontend. Payment always goes through Shopify's hosted checkout, and customization is limited to that framework (Checkout UI extensions and branding settings). That said, this also means that payments — the area with the heaviest security requirements — are delegated entirely to Shopify, so it is more accurate to understand this as a design philosophy rather than a constraint.

5. Full Control over robots.txt, sitemap.xml, and llms.txt

Though often overlooked, Hydrogen allows you to fully control the "entry point" files for search engines and AI, by managing them yourself.

robots.txt and sitemap.xml are treated as "routes" in Hydrogen. They are included in the skeleton (template) from the start; sitemap.xml is generated by fetching product, collection, and page URLs from the Storefront API, and page additions/deletions are automatically reflected within approximately one day. This means you can tailor the output to your site's structure, rather than relying on a fixed theme.

However, it's important to note that "being able to control" is different from "actually building it out." Hydrogen comes with a standard robots.txt (equivalent to Shopify's default rules), so customization is optional. Building on that, our own Hydrogen site implements these as custom routes. Our robots.txt combines crawl-control rules tailored to our URL structure with pointers for AI agents (a reference to llms.txt) and the locations of our sitemaps, and our sitemap.xml is automatically generated as an index split into pages, articles, and store — alongside a dedicated discovery sitemap for AI agents. How far to take this is up to each site, but the very ability to design these "entry points" around your own requirements is a freedom unique to Hydrogen.

Furthermore, the importance of llms.txt is growing. This file is used to structurally communicate "what this site is" to AIs like ChatGPT, Claude, Perplexity, and Gemini, and Shopify is rolling it out automatically to millions of stores. While Liquid stores automatically generate it without configuration, there are generally no means to finely override its content. In contrast, Hydrogen allows llms.txt to be treated as a route, enabling you to design and override what and how information is communicated to AI—this is currently the most practical customization opportunity. For brands with complex needs that cannot be fully expressed by automatic generation, such as multi-market expansion, B2B, or member-exclusive catalogs, this flexibility is highly effective (the significance of llms.txt itself is discussed in more detail in our other column).

However, this is a double-edged sword with the aforementioned benefits. "Being able to control it yourself" is synonymous with "having the responsibility to maintain it correctly yourself," and incorrect settings can risk harming SEO and how your site is perceived by AI.

6. Shopify Handles Member Login, While My Page Can Be Freely Designed

Regarding member functionality (My Page), Hydrogen adheres to the design philosophy of "Shopify handles the heavy lifting, you handle the appearance."

For login authentication itself, you can use Shopify's "Customer Accounts" mechanism directly. Hydrogen incorporates a dedicated client for this (Customer Account API), and the login process involves redirecting to Shopify's hosted authentication screen, then returning to your site after authentication, following an OAuth-based flow. This is a passwordless "new customer account" that authenticates with codes sent to email or Shop accounts, meaning you can delegate the most sensitive areas like password storage and authentication to Shopify, rather than implementing them yourself. Similar to payments, offloading security-heavy aspects to the platform provides significant peace of mind.

The login screen of our site

On the other hand, you can freely customize the My Page screen (order history, profile, shipping address, etc.). Data is retrieved via the Customer Account API, and the UI is implemented as your own components, allowing you to design a My Page that aligns with your brand's world view. This offers the best of both worlds: "relying on Shopify's robust authentication mechanism while designing the member experience ourselves" (in fact, our Hydrogen site's My Page is implemented with this configuration). While the login screen itself is Shopify-hosted, limiting visual customization, it also means there's no need to develop that part yourself.

7. Significantly Improved Developer Experience (DX)

Though often overlooked, Hydrogen significantly improves the "coding feel" for developers compared to Liquid. While Hydrogen has a steep learning curve, as discussed later, once a developer is proficient in React, the development experience is modern and comfortable.

• Type Safety: Hydrogen can automatically generate type definitions from GraphQL schemas. Autocompletion works for queries and data in the editor, and typos in field names can be detected at compile time. Liquid does have syntax checking (Theme Check), which catches grammatical errors locally or at upload time, but it lacks the concept of types: a typo in a field name raises no error and is silently rendered as an empty string at runtime. Such mistakes are often only noticed once the screen is rendered — or not at all.
• Modern Development Environment: It directly uses modern toolchains like Vite (hot reload with instant updates), TypeScript, Tailwind, and ESLint.
• Component-Oriented: UI can be reused, composed, and tested as React components. This makes it easier to maintain structure even in large-scale sites compared to Liquid sections and snippets.
• Open Ecosystem: A vast array of npm libraries (such as the 3D rendering and animations mentioned earlier) can be freely integrated.
• AI Compatibility: Being a standard React/TypeScript codebase, it's easier to leverage AI coding tools like Claude Code, and type checking acts as a safety net to catch "AI-generated errors."

In short, Hydrogen has the characteristic of being "difficult to learn, but once mastered, offers a powerful and comfortable development experience." Conversely, Liquid is "easy to learn, but has a low ceiling for what can be achieved." This asymmetry is an important factor in deciding the team structure and future development policies.

8. Ability to Design Your Own Data Retrieval and Search

For sites with a large number of products, the flexibility of "how much and how data can be retrieved" can be subtly effective. Here, let's clarify a common misconception.

Liquid has retrieval limits. Product loops are limited to 50 items by default, and even with the paginate tag, a maximum of 250 items per page is allowed, with pagination limited to the 25,000th item. Furthermore, retrieval is bound to "page rendering time," and you cannot control the content (fields or nesting) of the data retrieved yourself.

On the other hand, the idea that "Hydrogen (Storefront API) can retrieve everything without limits" is not entirely accurate. The Storefront API itself has similar limits to Liquid: "maximum 250 items per request" and "pagination up to the 25,000th item." This ceiling remains the same even with a different frontend.

So, what changes? The increase in flexibility isn't due to the removal of limits, but rather these three points:

• You can design your own queries: You can collectively retrieve only the necessary fields, including nested related data, using cursors on the code side, and then cache and process them on the server side (Oxygen). This offers a different level of freedom compared to "page-bound pagination that ties retrieval to rendering."
• You can use the Admin API and bulk operations: Since Hydrogen runs on the server side, if data not available through the Storefront API or all items exceeding 25,000 are needed, the "bulk operations" of the Admin GraphQL API can asynchronously retrieve all products and orders. Liquid cannot call these at all. Concrete use cases include generating product feeds for Google Shopping and the like, syncing a full index to an external search engine such as Algolia, and pre-computing aggregates across all products and orders. Since bulk operations are asynchronous and take time to complete, the practical pattern is not to run them per request, but to generate results in a scheduled job, store or cache them, and have Hydrogen serve them.
• You can freely choose your search engine: For product search and filtering, you can use Shopify's standard Search & Discovery (configured filters are available via the Storefront API), or if fast, high-performance search is required for large catalogs, you can replace it with a dedicated engine like Algolia or custom filtering logic. The ability to "select and design the search layer itself" offers a degree of freedom not found in themes.

In addition, if you want to store unique structured data (such as custom tables or specification data) other than product information, the storage location is also flexible. You can store it as Shopify's "metaobjects" and retrieve it via the Storefront API, or fetch and display it from your own or external APIs. The important point here is that regardless of the data source, if it's retrieved and rendered by Hydrogen's loader (server-side), its content will be included in the initial HTML delivered. This means that even data fetched from an external API, when passed through server-side rendering, will be readable by search engines and AI crawlers (whereas methods that only fetch and render on the browser side will not be in the initial HTML and will be less likely to be crawled). This allows you to freely structure information without being constrained by data origins, while maintaining an SEO and AI-friendly state.

There is one more secondary benefit on the security side. Shopify themes are, as far as external data fetching is concerned, an entirely frontend mechanism: calling an external API means calling it directly from the browser, which tends to require standing up middleware (such as a proxy server) in between to handle API-key secrecy and CORS. With Hydrogen, external APIs are called server-side (in loaders) and keys are kept secret as environment variables, so you avoid that architectural overhead altogether.

In essence, Hydrogen's strength isn't that "retrieval limits disappear," but rather that "you can design how to retrieve and how to search according to your own requirements."

Disadvantages: Limitations to Honestly Confront

While I've listed 8 benefits so far, don't be swayed by the sheer number of items. Each of the following disadvantages is significant and can, in some cases, negate multiple benefits. What's important is not the number of items, but evaluating how critical each one is for your company.

1. Some App Ecosystem Functionality Becomes Unavailable

Many apps from the Shopify App Store do not work out-of-the-box with Hydrogen. This is because most apps rely on injection into Liquid themes (via theme app extensions or ScriptTag), and Hydrogen, lacking a Liquid theme layer, has no point of attachment. This applies to UI injection-based apps such as review widgets, upsell pop-ups, loyalty displays, and live chat.

Only a limited number of apps that provide their own APIs/SDKs and React components (e.g., Klaviyo, Okendo, Recharge, Algolia, Gorgias, Rebuy) can be used with Hydrogen. Shopify offers an official collection of "Hydrogen-compatible apps," but this represents only a small fraction of all apps. Furthermore, even with these compatible apps, it's not a matter of just "installing them"; manual integration development is required. For example, with email marketing platform Klaviyo, events like "product viewed" or "add to cart," which are automatically captured in Liquid, need to be custom-implemented in Hydrogen. It's also worth noting that some vendors limit headless support to their higher-tier plans.

Determining "whether the apps you currently use or plan to use will work with Hydrogen" is a crucial point that must be checked in advance when making a headless decision.

2. Loss of Theme Editor and Need for a Separate Content Management System

Hydrogen lacks the visual theme editor (live preview) of Online Store 2.0. This means marketing teams can no longer directly edit banners or content from the admin panel and preview them on the spot.

To compensate, you'll need to implement a separate headless CMS or visual editor (such as Sanity, Builder.io, Pack, Storyblok, Weaverse). Conversely, by combining with an appropriate CMS, it is possible to recreate a content management environment where the marketing team can operate independently. However, this entails "additional selection, implementation, and operational costs." Going headless without a CMS often leads to developers needing to intervene and deploy even for a simple banner change, which is frequently cited as "the most regrettable point" of going headless. How content is managed is a topic that should be designed at the outset, with the same importance as technical selection.

That said, adopting a CMS is not merely the cost of replacing the theme editor. A headless CMS like Sanity is a dedicated content-management tool, and it can deliver efficiencies the theme editor never had — including support for agentic content updates driven by AI agents — so it can end up being a net benefit rather than a compromise. On our own Hydrogen site, we introduced Sanity for the careers pages so that the recruiting team can edit them directly.

3. Requires Specialized Personnel and Cost for Development and Maintenance

Hydrogen requires developers proficient in React/GraphQL/SSR. While Liquid can be learned in days to weeks, Hydrogen typically takes several months to master. As a result, initial build costs and total cost of ownership (TCO) over 3 years are estimated to be approximately 2-3 times higher than native Shopify configurations, according to calculations from multiple service providers (these are estimates and vary depending on scale).

Furthermore, a headless storefront is a "unique application" and requires ongoing maintenance indefinitely. Without a system and budget for post-launch maintenance, such as addressing security vulnerabilities in dependent packages, framework upgrades, and keeping up with quarterly API updates, technical debt will accumulate.

How much will AI (Claude Code, etc.) change this premise?

However, this premise that "specialized personnel are required" is rapidly being challenged by the advent of AI coding tools. With tools like Claude Code, tasks such as scaffolding (project templates), adding components, creating GraphQL queries, fixing common bugs, and adjusting visuals can be largely accomplished even by those without deep frontend expertise. For use cases like corporate websites where commerce logic is less complex, AI compatibility is particularly good. In fact, Shopify's new direction for Hydrogen in 2026 also emphasizes "agent (AI) compatibility," indicating that Hydrogen itself is moving towards greater ease of use with AI.

On the other hand, it's honest to say that AI won't take over everything. Diagnosing complex bugs related to SSR, caching, and hydration, dealing with the unique behaviors of edge runtimes, performance optimization, security, and adapting to quarterly breaking API changes—these "last 20%" still require a certain level of understanding. AI can also produce code that seems to work but breaks in production, and without the ability to detect such errors, there's a risk of rapidly accumulating technical debt.

Our assessment is that AI is dramatically lowering the barrier to entry, and the era is coming where even non-specialized teams can attempt to build and operate. However, it's important to note that the responsibility for maintenance itself doesn't disappear; it merely shifts from "the burden carried by specialists" to "the burden of utilizing AI and validating its output." To ensure production quality, an operational system that allows thorough verification, or a system where specialists provide support at key junctures, remains effective. Rather than thinking "it's safe because AI can build it," it's more realistic to view it as "the scope of what AI can build has expanded, making it crucial to design what you handle yourself and what you delegate."

4. Not "Automatically Faster"

It's a common misconception that Hydrogen will automatically make your site faster, which is not true. Shopify's own performance team explicitly states that "Hydrogen is not as fast as Liquid by default." Liquid, through years of runtime optimization, tends to have a high Core Web Vitals pass rate in its standard state. Hydrogen only surpasses Liquid in speed when full-page caching, sub-request caching, and data retrieval/rendering are meticulously implemented. Speed is not something you "get automatically," but something you "achieve through careful development."

Security Considerations: The Scope Shopify Protects vs. What You Must Protect

Often overlooked when considering headless is the security responsibility boundary. "Owning your own frontend" means "taking on some of the responsibility for protection yourself." Let's clarify this.

Scope Protected by Shopify (Security Inherited with Hydrogen + Oxygen)

• Payment and PCI DSS Scope: As mentioned, even with Hydrogen, payments are handed off to Shopify's native hosted checkout. Your frontend does not directly handle credit card information, meaning the most sensitive area concerning card data remains within Shopify's responsibility. This is a significant source of security assurance for headless implementations.
• Infrastructure Resilience: Infrastructure-level security, such as Oxygen server patching, DDoS protection, and scaling, is managed by the Shopify platform. This offers a clear advantage in significantly reducing the burden of dealing with OS and middleware vulnerabilities compared to setting up your own servers.

Areas Where Security Can Be Stronger Than With Themes

While headless generally means "increased responsibility," it also offers opportunities to enhance security in ways that were difficult with themes. A prime example is Content Security Policy (CSP). Hydrogen natively supports building CSPs (createContentSecurityPolicy), allowing you to enforce strict policies using nonces (one-time identifiers) that "only permit allowed scripts to execute." Our site also applies CSP using this mechanism. With Liquid themes, strict CSP implementation is often impractical because third-party apps inject arbitrary scripts into pages. Precisely because Hydrogen allows complete understanding and control over loaded scripts, it can elevate XSS (cross-site scripting) defenses.

Scope You Must Protect Yourself (Increased Responsibility with Headless)

• Vulnerabilities in Dependent Packages: A Hydrogen storefront is a "unique application" built on numerous npm packages. If vulnerabilities (CVEs) are found in dependent libraries, your company is responsible for tracking and updating them. This is an area that typically didn't require much attention with Liquid theme-centric operations.
• Vulnerabilities in Custom Code: Custom-implemented React components and API integrations can introduce implementation-related vulnerabilities such as cross-site scripting (XSS). The freedom to build your own frontend means you're also responsible for ensuring its security.
• Management of API Tokens and Secrets: Mismanaging private Storefront API tokens, various API keys, and environment variables can lead to information leaks or unauthorized use. Proper permission settings, rotation, and thorough concealment of tokens are required.

To summarize, the situation is that "Shopify handles the heaviest risks like card information and infrastructure, while your company takes on increased responsibility for application-layer security." This is two sides of the same coin as the "ongoing maintenance required" point mentioned earlier. Only with a system in place to continuously operate after launch, including updating dependent packages and monitoring for vulnerabilities, can headless security be maintained soundly. Conversely, precisely because you can build on Shopify's robust platform, you can also narrow down the scope of security that your company needs to focus on to the application layer.

Which Use Cases Is It Suitable For?

Based on the above, the cases for which Hydrogen + Oxygen is suitable, and those for which it is not, are relatively clear.

Suitable Cases

• URL design and crafting of the brand experience are directly linked to business value.
• Mid to large-scale operations with dedicated development and maintenance teams and budget.
• Desire to achieve a unique frontend experience that cannot be fully expressed with standard themes.
• Sites where structured information and content presentation are primary, preceding product display and sales (a structure where content is the starting point, and e-commerce is an extension).

The last point is particularly important. Liquid's design philosophy is commerce-centric, "centering on products and collections," which often makes theme frameworks feel restrictive for sites that prioritize information and content. Hydrogen, in contrast, allows you to make information architecture (site structure and URLs) the main focus according to your intentions, and then seamlessly integrate e-commerce functionalities on top. For corporate or brand websites where "there is information and a world-view to convey first, and product sales are an extension of that," Hydrogen's suitability stands out.

Cases Requiring Careful Consideration

• Limited budget or deadline.
• Existing site is sufficiently fast, and conversion rates are healthy.
• Focused on single-brand, simple operations.
• No resources or system to continuously maintain after launch.

If any of these apply, it's often true that going headless unnecessarily is not the best choice, and native Shopify (Liquid / Online Store 2.0) might be sufficient. Headless isn't inherently "better because it's new"; it's a choice to take on more cost and responsibility in exchange for flexibility.

Why We Rebuilt Our Corporate Website with Hydrogen

Finally, let's talk about our own experience. Flagship's corporate website released its Hydrogen version in July 2026. We weighed both the "suitable cases" and "disadvantages" mentioned above as challenges for our own company.

Firstly, one of the reasons we chose Shopify among the many CMS and site infrastructure options is that our corporate website is not just a company profile; it also features e-commerce functionality for selling merchandise (goods). We wanted to complete content delivery and product sales on a single platform—in that regard, Shopify, with its standard commerce features, was a natural choice.

Beyond that, our biggest reason for choosing Hydrogen was our desire to design the URL structure and frontend experience ourselves. A corporate website has diverse content such as columns, case studies, and service introductions, where information architecture and URL consistency directly impact the site's clarity and brand credibility. The ability to be freed from fixed URL constraints, to provide a smooth, app-like experience, and to design product sales (e-commerce) and content as a seamless experience was a clear value for us.

At the same time, we were aware of the disadvantages. We handle React-based development and maintenance ourselves, compensate for the loss of the theme editor with a separate content management system, and implement necessary app integrations via APIs. We can say that it was precisely because we had a system in place to continue maintenance that we took the plunge into headless. And the fact that Oxygen hosting was available at no additional cost was one of the factors that pushed that decision.

There is no single correct answer to the question "Should I adopt Hydrogen?" The important thing is to evaluate the three factors of flexibility, cost, and maintenance system based on your company's situation. We hope you will find our Hydrogen-based website to be a useful real-world example.

References and Sources

• Hydrogen and Oxygen fundamentals — Oxygen pricing and eligible plans (Shopify official)
• Liquid vs Headless: A Look at Real User Web Performance (Shopify Performance)
• Headless build options (Shopify official)
• Checkout UI extensions (Shopify official)
• SEO for Hydrogen – robots.txt / sitemap.xml (Official Shopify)
• Apps to Extend Hydrogen Build (Official Shopify App Store Collection)
• Shopify llms.txt Rollout and Customization in Hydrogen (Weaverse)

This column is based on official Shopify documentation and various primary sources (as of July 2026). Costs and other figures are estimates and may vary depending on scale and requirements. If you would like to discuss headless commerce or building with Hydrogen, please feel free to contact us.