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).
3 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.
3 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?
Hi @parkerproject , we are still working on rolling out this feature.
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