Can we hide project.onrender.com as I want the deployed app to be only accessible through my custom domain if cant remove onrender can we just make it password protected or something like a static page that says this service is archived and can be accessed using custom domain only
Hi @Mitesh_Metha ,
Can you help me understand why you’d want to not have the project.onrender.com domain available? If you are using custom domains and not sharing your project.onrender.com domain, it shouldn’t be visible to your users.
Thanks for the clarification—that makes sense. As long as you only share the custom domain (Custom Domains | Render · Cloud Hosting for Developers) and don’t share your onrender.com, you should be good. If you run into any issues with that, just let us know and I’ll be happy to help.
It would be nice if the project.onrender.com domain automatically redirected to the custom domain. For example, this is something that GitHub Pages does (username.github.io => custom domain if set up).
That’s a great idea I’ve added that as a comment to a general domain redirect feature request we’re tracking at Domain level redirects | Feature Requests | Render
Does Render prevent indexing of
projectname.onrender.com sites by search engines? I tried to retrieve a domain-level
onrender.com but it redirected me to
I’d imagine that would be really important. (A project obviously can’t serve its own
robots.txt disallowing everything, it would show up on the custom domain.)
projectname.onrender.com when you already have a custom domain, I’d like three options:
- Disable it completely <== This is what I’d use
- Redirect to the custom domain with a 301 (moved permanently)
- Serve the site (what it does currently)
(Or you could also offer a 302 option.)
Hi @tjcrowder, we do not prevent indexing, though I agree that this would be very convenient. As you probably saw, we’re planning to implement domain-level redirects, which would also prevent indexing by search engines.
Until we have built-in support, you can prevent indexing by specifying a canonical page, e.g. with
<link rel=canonical href="https://mycustomdomain.com/path" /> tags. For web services you could also inspect the host header to figure out whether the request was made to the custom domain or the onrender.com domain, and respond however you see fit.
Thanks. Yes, I’ve been looking into doing the
rel="canonical" links (or equivalent HTTP header). The problem is it’s One More Thing to get right, and awkward to set up sometimes.
My initial project won’t be impacted by this too badly, but…
I’m confused by what makes it difficult to not host the site at
onrender.com at all when there’s a custom domain in place (optionally, I guess, though I wonder if anyone would mind if it just always happened). That’s what every other service like this I’ve ever used did, either/or rather than both/and.
I’ve opened With custom domain, optionally disable onrender.com version | Feature Requests | Render. Hopefully it’s fairly simple to do.
Thanks for creating the feature request, T.J! We appreciate your help in making Render better.
Some additional data for this thread:
I recently noticed that a significant volume of malicious bot traffic was bypassing the Cloudflare block rules set up for the custom domain.
So I started logging the hostname derived from the Host HTTP header of requests. The data set is small at this point, but googlebot and bingbot are definitely crawling ‘site.onrender.com’. (Canonicals are already in place.)
I wrote some functions to block requests to domains other than the custom domain, and some additional code to duplicate the Cloudflare block rules at the application level to catch bots that forge the Host header.
As others mentioned, I would also like to have expertly implemented hosting level control over ‘site.onrender.com’, rather than relying on my own suspect code to get the job done!
Ugh! That sounds like No Fun. If you haven’t already, please upvote With custom domain, optionally disable onrender.com version | Feature Requests | Render.
Any updates with this request?
Hi @parkerproject , we are still working on rolling out this feature.