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
2 Likes
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.
Not a specific reason but I would like the Nodeapp restapi should be access using api.domain.com rather than app.onrender.com
Althought I would be using api.domain.com everywhere but Just didnt want user to know theres another way to reach service via onrender.com
1 Like
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).
2 Likes
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
4 Likes
Does Render prevent indexing of projectname.onrender.com sites by search engines? I tried to retrieve a domain-level robots.txt from onrender.com but it redirected me to render.com.
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.)
Re the 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.)
TIA,
– T.J.
3 Likes
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.
1 Like
Hi @david,
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,
– T.J.
2 Likes
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!
+1
1 Like
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?
It’s mind boggling to me that this isn’t available yet. Why do we have to try and convince you that it’s insane to “just not publish it on the internet”. Are we now supposed to set random project names, just so we can avoid being spammed by crawlers bruteforcing subdomains on *.onrender.com?
It’s not a “convenience”, it should be a given. People are spinning up servers and putting sites on the internet. How is anyone supposed to choose Render from the myriad of XaaS providers when we can’t event control which domains can be used to reach our content? Well, on to the next PaaS, I guess.
Hi Andrei,
Thanks for reaching out and for taking this time to give feedback.
We have a planned feature request for more control over the default domain, which I see you have cross-posted on.
Having a canonical domain is certainly desirable. On production Web Services a workaround may be to set up a redirect within the code to respond with a 301. For Static Sites, that workaround doesn’t fit so well as the redirect would need to be client-side, which wouldn’t be a great experience.
Are you referring to any particular service-type or feature set here, or all publicly available services? Would this be more related to staging apps or preview environments, that you likely wouldn’t want to be public facing?
Thanks again for your feedback
Alan