Generative Engine Optimization (GEO) is the set of technical and content practices that make a site easier for generative search engines and AI-based conversational assistants (ChatGPT, Perplexity, Gemini, Claude) to read, cite, and recommend, unlike traditional SEO, which optimizes for ranking in search engine results pages (SERPs). While classic SEO primarily focuses on keywords and backlinks, GEO focuses on recognizable entities (who you are, what you do, with consistent data across the site), structured data (schema.org/JSON-LD) that explicitly states facts otherwise implicit in the text, and content written in a way that allows a language model to extract a correct passage without misunderstandings. It also includes technical accessibility for AI crawlers (a robots.txt that does not block known bots, files like llms.txt or agents.md) and the elimination of hidden or contradictory content, which a generative engine tends to penalize or ignore. For an SME on Shopify, applying GEO practically means: consistent markup on every page, a single version of business facts, and content that immediately answers the user's question instead of arriving at it after many lines of introduction.

llms.txt is an emerging convention (not an official web standard) that proposes publishing a Markdown-formatted text file in a website's root directory, designed to guide large language models (LLMs) towards the most relevant content on that site, similar to how robots.txt guides traditional crawlers on crawling rules. It does not replace sitemaps or structured data; it is a synthetic, machine-readable index that lists the pages or sections that a site considers most significant for citation. On Shopify, since the platform change in late May 2026, the /llms.txt root is natively served by the platform itself for every store, and also acts as a fallback for /agents.md and /llms-full.txt; the only way for a merchant to intervene in this content is via a dedicated theme file, no longer via an application proxy. It is therefore one piece of GEO, not the only one: a well-maintained llms.txt does not compensate for missing structured data or contradictory content elsewhere on the site.

agents.md is the file, served at the root of the domain, which Shopify uses to describe in a textual and structured way—designed to be read by an AI agent rather than a person—who manages a store, what services they offer, and where to find verification sources (reviews, profiles, contacts). As of May 28, 2026, it is also the platform's official mechanism for responding to requests for /llms.txt and /llms-full.txt: if these paths do not have their own content, the response will still come from agents.md. The typical content is a precise list of links (services offered with their respective URLs, profiles where reputation can be verified by third parties, contacts): an AI agent extracts a list of direct references more reliably than a descriptive introductory paragraph. For a merchant, keeping it updated and consistent with the rest of the site (same services, same links, same way of describing the business) is more useful than seeking alternative channels to speak to AI crawlers: it is the channel already managed by the platform itself, so there is no need to duplicate it elsewhere.

Schema Markup is a standardized vocabulary (schema.org) added to a page's code to explicitly describe, in a machine-readable format, what that content represents: a product, its price, an article with its author and publication date, a company with its address. On Shopify, it is almost always implemented with JSON-LD, a dedicated script inserted into the page, separate from the visible HTML markup. Without Schema Markup, a search engine or AI assistant must deduce the meaning of the content solely from the text and visual structure; with Schema Markup, that information is declared once, unambiguously. It is the technical basis for both rich snippets in search results and the citability of a site by generative search engines: an entity (person, company, product) described with a consistent identifier across all pages prevents the same fact from being interpreted differently from page to page. It should only be used to describe what is actually visible and verifiable on the page: declaring data in the schema that does not appear on screen, or a value different from what is shown, is considered by Google's guidelines to be an incorrect practice.

A rich snippet is an enhanced search result that a search engine like Google displays thanks to structured data (schema markup) present on a page: rating stars, product price and availability, or the question and answer structure of an FAQ. It is not the markup itself, but its visible effect on the results page: a normal ad only shows the title, URL, and a text description; a rich snippet adds visual elements that take up more space and communicate more information even before the click. Obtaining a rich snippet is not guaranteed by adding schema markup: the search engine decides if and when to display it, and may stop doing so if it detects a mismatch between the data declared in the schema and the content actually visible on the page. For this reason, a rich snippet should be treated as a possible consequence of correct and consistent data, not as a goal to be forced with unverifiable values.

Core Web Vitals are the official metrics Google uses to measure the real-world user experience of a web page, and they are also a SEO ranking factor. The three current metrics are: LCP (Largest Contentful Paint, the time it takes for the largest visible element in the first screen to load), INP (Interaction to Next Paint, the responsiveness of the site to user interactions throughout the entire session — it replaced First Input Delay as the official metric in March 2024), and CLS (Cumulative Layout Shift, how much the page visually shifts while loading). Google defines a 'good' threshold for each metric, measured on real user browsing data, not just in a lab test. On Shopify, the most common causes of poor Core Web Vitals are unoptimized themes, too many third-party apps loading additional scripts, and incorrectly sized images. Improving Core Web Vitals is a technical job on the theme code and the number of scripts loaded, not an aesthetic intervention.

Largest Contentful Paint (LCP) is one of Google's three Core Web Vitals metrics and measures the time it takes from when the page starts loading until the largest visible element in the viewport (typically a hero image or large heading) appears on screen. Google considers an LCP within 2.5 seconds to be 'good'; beyond 4 seconds, the page is classified as 'poor'. On a Shopify e-commerce store, a slow LCP is often caused by excessively large or unoptimized images, the loading of non-critical fonts before main content, or third-party scripts that occupy the browser's main thread before the key element is rendered. A high LCP is not just a technical problem: several independent studies link loading delays to an increased bounce rate, especially on mobile. The main techniques to improve it include preloading critical resources, compressing and correctly sizing images, and reducing non-essential JavaScript code loaded before rendering.

Interaction to Next Paint (INP) is Google's Core Web Vitals metric that measures a page's responsiveness to user interactions (clicks, taps, key presses) throughout the entire visit, not just the first interaction. It officially replaced First Input Delay (FID) in March 2024 because FID only measured the delay of the very first interaction, whereas INP observes all interactions during the session and records the slowest one. Google considers an INP within 200 milliseconds to be 'good'. On an e-commerce site, a high INP is perceived as a site that feels 'stuck': a click on a menu, opening the cart, or selecting a product variant that responds with a noticeable delay. The most common causes are heavy or poorly optimized JavaScript scripts (often introduced by unchecked third-party apps), event handlers that perform too much work on the browser's main thread, and unoptimized animations. Reducing the number and weight of loaded scripts, and preventing code from blocking the main thread during an interaction, are the main interventions to improve it.

Technical debt is a concept from software engineering that also applies to Shopify development: it indicates the accumulation of quick or poorly structured technical choices – code written in a hurry, apps installed without verifying their impact, customizations layered over time without a consistent design – which save time in the short term, but in the medium to long term make the store slower, more fragile, and more expensive to modify. The term is borrowed from finance by analogy: like monetary debt, it generates 'interest' that is paid over time in the form of worse performance, more frequent bugs, and greater difficulty introducing new functionalities without breaking something that already works. On Shopify, technical debt typically manifests through the accumulation of apps installed for specific needs and never removed, undocumented custom Liquid code, and the layering of different solutions for the same problem over time. It is not a one-time mistake: it is a process that gradually accumulates, and requires dedicated periodic maintenance, not just a corrective intervention when the problem becomes visible to users.

App reduction refers to the approach of preferring to implement a feature with native theme code (Liquid, theme blocks, functionalities already included in Shopify) rather than installing a third-party app to achieve it. Every installed app typically injects additional JavaScript and CSS code into the store's frontend, which must be downloaded and executed by every visitor's browser regardless of how many app features are actually used. This is one of the most common factors contributing to the deterioration of Core Web Vitals (especially INP and LCP) and increased monthly recurring costs. App reduction does not mean 'zero apps whatsoever' — for complex functionalities or those requiring their own backend, an app often remains the most sensible choice — but rather evaluating, feature by feature, whether there is already a native way to achieve it before adding another layer of external dependency. For an SME, the practical benefit is twofold: fewer monthly subscriptions to pay and a lighter, more responsive store, because every third-party script less is a lighter load for the user's browser.

Online Store 2.0 (often abbreviated as OS 2.0) is the Shopify theme architecture introduced starting in 2021, based on JSON templates rather than entirely on static Liquid files. The main feature is that every section of the theme (not just those on the homepage, as in the previous architecture) can be added, removed, reordered, and customized by the merchant directly in the theme editor, without modifying any code. This applies to product pages, collections, blogs, and custom pages. The architecture also introduces 'app blocks' and, in more recent themes, 'theme blocks,' which allow third-party apps to add content directly into theme sections via the editor, instead of having to inject scripts through less controllable mechanisms. Metafields can be natively linked to blocks via the editor, without writing code. For a merchant, the practical advantage of OS 2.0 is greater autonomy in customizing the store's layout without having to involve a developer for every minor structural change, while still maintaining the ability to intervene in the Liquid code when deeper customization is needed.

A Theme App Extension is the official mechanism by which a Shopify app injects content or functionality directly into an Online Store 2.0 theme, in the form of an 'app block' (a block that the merchant adds and positions within a section via the theme editor, just like a native block) or an 'app embed' (a globally activatable block, for example, a floating widget visible on all pages). The extension's code lives in a separate package managed by the app; it does not directly modify the merchant's theme files: when the app is uninstalled, its block simply ceases to be available, without leaving orphaned code within the theme. This is why it is Shopify's preferred mechanism over direct script injection into the theme: it is isolated, reversible, and visible to the merchant in the editor, who decides where to place it and can remove it at any time. Theme App Extensions have a technical size limit on the total Liquid content of blocks (100 KB), designed to prevent an extension from uncontrollably burdening the theme.

A metafield is an additional data field that can be linked to an existing Shopify resource—a product, collection, page, customer, or the entire store—to store information not provided by the platform's native fields. Examples include technical specifications for a product or a specific warranty text for a category. Each metafield has a definition (the type of data it contains: text, number, image, reference to another resource) and a value for each individual resource to which it is applied. In Online Store 2.0 themes, metafields are linked to theme blocks directly from the editor, without writing code, or can be called from custom Liquid code for finer control over rendering. It is the native tool for avoiding the installation of a dedicated app just to add an additional data field to product pages. The practical difference compared to a Metaobject is that a metafield always remains 'attached' to an existing resource, whereas a Metaobject is a standalone data type with its own structure.

A Metaobject is a custom, standalone data type on Shopify, with its own structure and entries (the actual records), which does not depend on being linked to a pre-existing native resource, unlike metafields. It is useful when you need to model an entity that the platform does not natively provide and that can be linked to multiple resources simultaneously: for example, a designer or brand profile, which can be linked to many different products, or the entries of a size chart shared by an entire collection. The practical advantage is centralization: if the information changes, it is modified only once in the Metaobject and the change is automatically reflected wherever that entry is referenced, instead of having to update the same repeated data on each individual product page. Like metafields, Metaobjects can be linked to theme blocks from the editor without writing code, or called by custom Liquid: they are often proposed as a native alternative to apps that manage 'custom fields' or small content databases for the theme.

Shopify Functions è il meccanismo con cui gli sviluppatori possono personalizzare alcune logiche di backend di Shopify, per esempio sconti, regole di validazione del carrello, opzioni di spedizione o altre estensioni supportate, eseguendo codice nell'infrastruttura Shopify invece che tramite script fragili nel browser. Le capacità disponibili dipendono dall'API, dal tipo di Function, dal piano e dalle condizioni correnti della piattaforma. Ha progressivamente sostituito approcci precedenti più limitati. Per un merchant il vantaggio pratico è poter introdurre logiche personalizzate attraverso estensioni progettate per integrarsi con l'architettura della piattaforma, mantenendo espliciti requisiti e compatibilità del singolo progetto.

Checkout Extensibility is the architecture through which Shopify allows checkout customization via extensions (Checkout UI Extensions) developed and distributed as apps, rather than by directly modifying the checkout layout file (the previous approach, based on checkout.liquid, which is now deprecated). Customizations—for example, an additional field in the form, an informational banner, an upsell on the summary page—are executed in an isolated environment (sandbox) separate from the core checkout code: an error in an extension cannot block the entire purchase process, and updates that Shopify releases to the checkout do not risk breaking existing customizations, because they remain on separate tracks. For merchants who previously invested in direct customization of the old checkout.liquid, migrating to Checkout Extensibility has involved the need to rebuild those customizations in the form of extensions, a specific but unavoidable development task, given that Shopify has deprecated the old mechanism. The benefit is a more stable checkout over time and less exposed to conflicts between scripts from different sources at the same critical point in the sales funnel.

Con “B2B nativo” si indicano le funzionalità che Shopify mette a disposizione per gestire vendite business-to-business, come cataloghi, prezzi o condizioni commerciali dedicate. La disponibilità concreta delle singole funzioni cambia in base al piano, al mercato e alla configurazione dell'account, quindi va verificata sul progetto reale prima di promettere un flusso specifico. Nel mio lavoro valuto esclusivamente ciò che è disponibile sui piani Shopify Basic, Shopify e Advanced e, quando una necessità non è coperta nativamente, considero un'integrazione o uno sviluppo alternativo compatibile.

Agentic Commerce refers to the set of transactions in which an AI-powered assistant (an 'AI agent', for example integrated into ChatGPT or another conversational assistant) acts on behalf of a person: it searches for a product according to specific criteria, compares alternatives from multiple stores, and in some scenarios even completes the purchase, with the user only intervening to confirm or define the initial constraints of the request. It's a change in how a potential customer can reach a store: not just a human visitor navigating pages and clicking buttons, but also an automated agent that must be able to reliably read and extract catalog information (availability, price, product characteristics), usually through structured data and APIs, rather than through the visual interpretation of a page designed for a human. For a Shopify merchant, preparing for Agentic Commerce practically means having correct and structured product data (schema markup, feeds, consistent metafields), rather than designing a dedicated visual interface. This is still an evolving area, not a fully consolidated technical standard.

AI Search (or generative search) refers to search engine functionalities that, instead of returning a simple list of links, generate a synthetic written answer based on multiple sources, often citing or linking some of them. The most well-known example is Google AI Overviews (previously in experimental phase as SGE — Search Generative Experience), in addition to conversational answer engines like Perplexity or the integrated search function in ChatGPT. For a website, being cited in a generative answer does not depend on the same signals as traditional search: ranking position matters less, while clarity and verifiability of content, the presence of structured data that makes key facts explicit, and the consistency of information across the entire site matter more. A growing portion of user searches, especially those with an informative intent, now conclude without a click to any website (so-called 'zero-click' searches), because the generated answer is already sufficient: this makes it even more important that, when a generative engine cites a source, that source is correct and recognizable as authoritative on the topic.

Consent Mode v2 is the updated version of Google's mechanism that allows a website to communicate to Google Ads, Google Analytics, and other Google tags the consent status expressed by a user (for example, through a cookie banner) regarding data processing for advertising and personalization. Unlike the previous version, Consent Mode v2 introduces two new dedicated consent parameters, which have become a requirement for merchants operating in the European Economic Area and using Google's advertising tools. On Shopify, this is typically integrated through a consent management platform (for example, Iubenda) that connects to the Google tags installed on the store: if the integration is not configured correctly, consent signals are not transmitted, and advertising platforms receive incomplete or distorted data on actual conversions, which can skew optimization decisions for advertising campaigns. It is therefore a compliance issue (in the context of GDPR/ePrivacy) with a direct technical impact on the quality of marketing data, not just an isolated legal requirement.