Option to Disable Public *.mintlify.app Domain #4753
Replies: 4 comments
|
I wanted to add to this that it's made searching for Mintlify pages via Google a little more challenging lately as well. I will often use Google to find a page in the Mintlify docs I know exists, e.g. Google search "Mintlify Workflows". A lot of the autogenerated Mintlify sites now show up in search results and I'm finding myself clicking into other products unintentionally. |
|
Concrete impact: Google has selected our lexq.mintlify.app URLs as canonical over our custom domain (docs.lexq.io) for brand queries, despite correct canonical tags on every page — confirmed via curl and GSC. Support confirmed no server-side redirect exists today. A 301 from the default subdomain to the connected custom domain (or an opt-out toggle) would fix this class of SEO leak for every custom-domain tenant. |
|
I've experienced the same as @sanghyunp-dev - Google has selected our .mintlify.app subdomain as canonical over our custom domain despite us setting correct canonical tags everywhere. A simple 301 redirect or the ability to disable the mintlify subdomain would resolve this. |
|
Same here, leetcode-py.mintlify.app vs leetcode-py.wisl.dev. Every page on both hosts serves the wisl.dev canonical (checked with curl on the homepage and a bunch of the 310 problem pages), and robots.txt on the shared subdomain points its sitemap at the custom domain too. Google still serves the mintlify.app URLs in results and site:leetcode-py.wisl.dev returns nothing. GSC shows the custom domain pages as crawled but not indexed, so they're getting folded into the mintlify.app cluster. There's not much left on my side. The repo README, the GitHub website field and the PyPI page all link the custom domain. A 301 from the default subdomain, or an opt-out toggle, would fix it. |
Uh oh!
There was an error while loading. Please reload this page.
I’d like to propose a feature that would significantly improve security and access control for documentation projects.
Currently, even when using a custom domain, the default
*.mintlify.appdomain remains publicly accessible. This creates a problem for setups where documentation is intended to be private or protected, for example, when served behind tools like Cloudflare Access.In our case, we are using the free tier and hosting docs behind access control on a custom domain, but the Mintlify subdomain still exposes the same content publicly, effectively bypassing those restrictions.
Request:
Introduce an option to disable or restrict access to the default
*.mintlify.appdomain.Why this matters:
Additional context:
If this feature is only planned for paid tiers, it would still be helpful to know, although in our case, upgrading is not an option at the moment, so a free-tier-compatible solution or workaround would be especially valuable.
Thanks for considering this -- happy to provide more details if needed!
All reactions