How to Configure /.well-known/ Files on Webflow Premium

Webflow's May 13, 2026 Premium plan update included well-known files as a built-in feature. Before this week, hosting a file at the /.well-known/ path on a Webflow site required a Cloudflare Worker, a separate subdomain, or another CDN workaround. As of May 13, the Premium plan supports the path natively. For Phoenix Studio, this removes the most common reason I have shipped a custom CDN layer alongside a Webflow build, which is hosting apple-app-site-association for a client's iOS app. In this tutorial I walk through configuring well-known files for the three most common use cases: Apple universal links, Android App Links, and emerging llms.txt for AI crawler permissions. Each section is end-to-end with verification.

What changed in Webflow's Premium plan for well-known files?

The Webflow Premium Site plan launched on May 13, 2026 includes hosting for /.well-known/ files as a built-in feature, alongside file form upload and faster search indexing. The capability was previously a workaround that required external infrastructure. New Premium plan purchases get the feature immediately. Existing Workspaces migrate to the new Premium baseline at their next renewal on or after June 29, 2026.

The full feature list for the new Premium plan is in the Webflow Help Center plan FAQ. The Webflow Updates feed and the Webflow blog announcement both call out well-known files as a new inclusion. For solo Webflow Partners with active iOS or Android app client work, this is one of the more practically useful additions to the new plan structure. The piece on the full Premium plan capability list covers the broader plan changes alongside this specific feature.

Why were well-known files a workaround on Webflow before May 13, 2026?

Well-known files require hosting a file at a path that begins with /.well-known/ and serves with a specific content type, typically application/json for Apple and Android files. Webflow's previous Site plans did not surface a way to configure the /.well-known/ path directly, because the path is reserved by IETF RFC 8615 and Webflow's CMS routing did not include explicit support for the reserved path. Workarounds used Cloudflare Workers, custom subdomains, or third-party CDNs to serve the file at the correct path.

The IETF specification at RFC 8615 defines the /.well-known/ path as a standardized location for site-wide metadata. The IANA registry lists the registered URIs, including apple-app-site-association, assetlinks.json, and dozens of others used for verification, security, and protocol discovery. Webflow's Premium update on May 13 adds native support for the reserved path inside the Designer site settings, removing the workaround requirement for the common cases.

How do I add an apple-app-site-association file in Webflow today?

To add an apple-app-site-association file on Webflow Premium, open the Webflow Designer, go to Site settings, find the Well-Known Files section, choose apple-app-site-association as the file type, paste the file contents formatted as Apple's expected JSON structure, save, and publish the site. The file will then be served at https://yoursite.com/.well-known/apple-app-site-association with the correct content type automatically.

The Apple universal links specification at developer.apple.com documents the expected JSON structure for the file. The typical content includes the Team ID and Bundle ID of the iOS app, the paths that should open in the app instead of the browser, and any additional configurations for app clips or shared web credentials. The Webflow side of the configuration is purely the file content. The iOS app side requires the corresponding entitlements and associated domains configuration, which lives in the Xcode project rather than in Webflow. The piece on the Webflow Premium plan capability list covers the other features that ship with Premium and pair well with this one.

How do I deploy assetlinks.json for Android App Links?

To deploy assetlinks.json on Webflow Premium, follow the same path as for apple-app-site-association: Site settings, Well-Known Files, choose assetlinks.json as the file type, paste the file contents formatted as Google's expected JSON array, save, and publish. The file will be served at https://yoursite.com/.well-known/assetlinks.json with the correct content type automatically.

The Android App Links specification at developer.android.com documents the expected JSON array structure. The typical content includes the Android package name of the app, the SHA-256 fingerprints of the app's signing certificate, and the relations the app declares for the domain, typically delegate_permission/common.handle_all_urls. The Android side of the configuration requires the corresponding intent filters and digital asset link verification in the AndroidManifest.xml of the app, which lives in the Android Studio project rather than in Webflow. The file itself is the only piece that lives on the Webflow site.

Should I host an llms.txt file for AI crawlers?

Yes, for most B2B SaaS Webflow sites that want AI crawlers like ClaudeBot, GPTBot, and PerplexityBot to find and parse the site's most authoritative content. The llms.txt file is a community proposal from Jeremy Howard that sits at /.well-known/llms.txt and lists the URLs that AI crawlers should prioritize for ingestion. It is not yet a formal standard, but the major AI crawlers increasingly read it.

The format is a markdown file with a top-level project description, a list of key URLs with one-line summaries, and optional sections for documentation, API references, and tutorials. For a B2B SaaS marketing site, the relevant URLs are typically the homepage, the product overview, the pricing page, the docs index, and the most authoritative blog posts. The Webflow Designer side is the same as for apple-app-site-association: paste the file contents into the Well-Known Files section of Site settings and publish. The file is then served at https://yoursite.com/.well-known/llms.txt and discoverable by AI crawlers that look for it.

How do I verify the file is served correctly at /.well-known/?

Verify the file is served correctly by opening the relevant verifier tool for the file type. For apple-app-site-association, use Apple's Universal Links validation in Xcode or the Apple App Search API Validation Tool. For assetlinks.json, use Google's Digital Asset Links API tester. For llms.txt, use a manual HTTP request to https://yoursite.com/.well-known/llms.txt and confirm the response includes the correct content type header and the expected file content.

The fastest manual verification is a browser visit or a curl request to the full URL. The response should be HTTP 200, the content should match what was configured in Site settings, and the Content-Type header should match the expected type for the file. For apple-app-site-association and assetlinks.json the content type is application/json. For llms.txt the content type is text/plain or text/markdown. Webflow handles the content-type configuration automatically based on the file type selected in the Well-Known Files section.

Does well-known file hosting work on the Basic plan or only Premium?

Well-known file hosting is included in the Premium plan only as of May 13, 2026. The Basic plan does not include native /.well-known/ support. Sites on the Basic plan that need to host well-known files continue to require an external workaround. Existing legacy plans (CMS, Business) retain their original configurations until migration to the new structure at their next renewal.

For Phoenix Studio's mix of clients, the typical pattern is that any client serious enough to need apple-app-site-association or assetlinks.json for an iOS or Android app is already on a plan that justifies the Premium upgrade. The handful of clients on Basic who do not need well-known files are unaffected. The discipline is to evaluate the plan tier against the actual feature requirements rather than to upgrade everyone to Premium reflexively. The piece on the Premium plan capability list covers the broader plan migration decision.

What happens to my existing Cloudflare Worker workaround?

Existing Cloudflare Worker workarounds for /.well-known/ files continue to work after the May 13, 2026 Premium update. The Worker still intercepts the path and serves the file. The choice to migrate to native Webflow hosting is operational: removing the Worker simplifies the infrastructure stack and removes a third-party dependency, but requires reconfiguring the file inside Webflow Site settings.

For Phoenix Studio, I am removing three Cloudflare Worker workarounds from client stacks this month, replacing them with native Webflow hosting on Premium. The migration takes about 15 minutes per client: configure the file in Webflow Site settings, publish the site, verify the new endpoint serves the file correctly, then disable the Cloudflare Worker that was intercepting the path. The Worker can be deleted after one or two weeks of confirmed native operation. The simpler stack reduces the ongoing maintenance burden and removes a recurring monthly Cloudflare cost line item.

How does this connect to Webflow's faster search indexing in the same update?

Webflow's May 13, 2026 Premium update includes faster search indexing alongside well-known files and file form upload. The faster search indexing pertains to Webflow's internal site-search feature, which crawls and indexes CMS content for the on-site search UI. The two features are independent but complement each other: well-known files signal to external crawlers what content matters, while faster search indexing helps internal site search return current content.

For B2B SaaS Webflow sites with substantial CMS content, the combination of well-known files for external AI crawlers and faster internal search indexing for on-site queries covers both reader patterns. The native Webflow features now handle what previously required additional plugins or custom workarounds. The discipline is to use both features deliberately rather than reflexively: hosting llms.txt only when the site has content worth surfacing to AI crawlers, and tuning internal search indexing only when the CMS volume justifies it.

When should I add additional well-known URIs from the IANA registry?

Add additional well-known URIs from the IANA registry when the corresponding protocol or verification is part of the site's operational requirements. The most common additions beyond Apple, Android, and llms.txt are security.txt for security disclosure, openid-configuration for OpenID Connect, and various WebFinger-related URIs for federation. Each URI has a specific format and a specific consumer that reads it.

The general discipline is to add only the well-known URIs that something actually reads. A security.txt file makes sense if the site has a security disclosure program. An openid-configuration file makes sense if the site is an OIDC provider. Adding URIs reflexively because they exist in the IANA registry adds maintenance overhead without delivering value. The Webflow Site settings panel surfaces the well-known files configuration in a clean interface that makes adding new files easy, but the discipline of adding only what is needed compounds across the site over time.

If you are setting up well-known files on a Webflow Premium site and want to talk through which files actually earn their place for your specific use case, drop me a line and tell me what apps or services need to verify the domain. I will share the configuration I am running on Phoenix Studio client sites this week. Let's chat.