How Wix Handles robots.txt for Stores
Wix generates a robots.txt file automatically for every site, including Wix Stores. The file lives at yourdomain.com/robots.txt and is system-managed — meaning Wix controls the base structure and you cannot replace it with a fully custom file the way you can on Shopify or a self-hosted platform. What you can do is edit specific directives through the Wix SEO Settings panel, which appends your rules into the generated output.
For ecommerce operators, this architecture matters immediately. Product pages, collection pages, cart URLs, and checkout flows are included or excluded based on Wix's defaults and whatever overrides you apply through the dashboard. Understanding which paths are blocked by default — and which need manual attention — is the first task when auditing a Wix store's crawl configuration.
Default robots.txt Behavior on Wix Stores
Out of the box, Wix blocks several internal paths that should never be crawled: /_api/, /_partials/, and various system folders used by the Wix infrastructure. These blocks are appropriate and should not be removed. Checkout pages (typically under /checkout) are also blocked by default, which is correct behavior — checkout flows hold no indexable value and should stay out of search engines.
Collection pages and product pages are allowed by default, which is the correct baseline for a store. However, Wix also generates faceted URLs when shoppers filter by category, price, or attribute. These filtered URLs — often structured as query strings like ?sort=price or ?filterByCategory=shoes — are crawlable unless you explicitly manage them. Left unaddressed, they create duplicate content at scale, diluting crawl budget on large catalogs.
The Wix-generated sitemap is referenced in the robots.txt file automatically via a Sitemap directive. This reference points to the XML sitemap Wix builds, which includes product and collection pages. Verify the sitemap URL in your robots.txt is the correct domain — especially after connecting a custom domain — because mismatches between the sitemap host and the robots.txt host confuse crawlers.
Editing robots.txt Directives Inside Wix
Access robots.txt controls through the Wix dashboard: go to Marketing & SEO → SEO Tools → Advanced SEO → Robots.txt. The editor presents a text interface where you add Disallow or Allow rules for specific user-agents. Changes made here are injected into the auto-generated file — they do not overwrite the protected system blocks, but they do appear alongside them in the final output.
Rules you should add for a typical Wix store include: blocking internal search result URLs (Disallow: /?q=), blocking sort and filter query parameters if Wix does not canonicalize them correctly for your store, and confirming that /account/ and /my-account/ paths are disallowed so that logged-in customer account pages are not indexed. Test every change at yourdomain.com/robots.txt immediately after saving — Wix applies changes quickly, usually within minutes.
One firm limitation: you cannot set rules per crawl-delay for specific bots, and you cannot add non-standard directives beyond what Wix's parser accepts. If you need highly granular per-bot rules (for example, different Disallow paths for Googlebot versus Bingbot), the Wix interface does not support that level of segmentation. Work within what the editor allows and rely on canonical tags and noindex meta tags to handle edge cases that robots.txt cannot address on this platform.
Wix Apps, Third-Party Tools, and robots.txt Interaction
Several apps in the Wix App Market generate their own URL structures that affect what should be in robots.txt. Wix Blog, Wix Bookings, and Wix Events each create new path patterns. If any of these run alongside a Wix Store, audit those paths: blog tag pages, booking confirmation URLs, and event draft pages are common sources of low-value crawlable URLs that belong in a Disallow rule.
Third-party SEO apps available on Wix — such as SEOSpace or Semrush's Wix integration — provide robots.txt auditing and recommendations but do not bypass the platform's editing restrictions. They surface issues but you still make changes through the native Wix SEO Tools interface. No third-party app can grant full file-replacement access; the file remains under Wix's control.
If a Wix store uses Wix Headless (Wix's API-based approach where the frontend is hosted elsewhere), the robots.txt situation changes. The frontend domain's robots.txt is managed on the external host, while the Wix backend handles its own. In a headless setup, confirm which domain search engines are intended to index and ensure the robots.txt and canonical configuration on the frontend domain are consistent with that intent.
Actionable Configuration Checklist for Wix Store Operators
Start by fetching your live robots.txt and confirming the Sitemap directive points to the correct custom domain, not a wixsite.com subdomain. Then verify /checkout, /_api/, and account-related paths are disallowed. Add explicit Disallow rules for internal search queries (?q=) and any filter or sort query strings your store generates that Wix does not automatically canonicalize.
Next, check that no product pages or collection pages are accidentally disallowed — a misplaced wildcard rule in the Wix editor can block entire URL trees. Use Google Search Console's URL Inspection tool to confirm that representative product URLs are marked as 'Allowed by robots.txt' after any changes. Run this check after every edit, not just during initial setup.
Finally, document your robots.txt configuration in writing and revisit it whenever you add a new Wix app, restructure your store categories, or launch a new product line. The Wix editor does not maintain a version history of robots.txt changes, so external documentation is the only record you will have if a rule needs to be rolled back.