Since we can’t delete a deploy, here is a way to alleviate the case you don’t want to have the branch deploys.
Branch for preview (temporarily)
- Set your production site with no previews and branch deploys under Continuous Deployment
- Set up a [new site] to the same repo and build the branch
- Delete the [new site] when no longer needed
- Rinse and repeat
Yes, I was thinking about testing this approach in the end. My only concern (I have to test) is that it forces us to update the dns for the subdomain (CNAME pointing to a random Netlify ID that will change with the new website)
You don’t even need to set DNS up - you could always use the netlify sitename (which you can also change to be something consistent like
beta-mycompany.netlify.com for each site you set up and then delete in sequence).
If you use Netlify’s DNS hosting, we’ll also automatically “do the right thing” for records like that and remove and recreate them for you to be correct.
I’m facing the same problem,
I Just deleted the branch in bitbucket and still sub domain exist !!
and also tried to delete it’s DNS Records but it didn’t work “This is a system record that cannot be managed directly.”
Hi @Miggz. Welcome to our community!
Support can delete Netlify-created DNS records for you. Let us know the name of the site and the name of the record and we can take care of it. If you’re not comfortable posting that here, please mention that, and we’ll DM you.
If we still can’t delete deployments could at least unpublish a branch URL so it is not available?
I’ve be using a preview deploy but there appears to be issues with the role based gating not on main deploy. I want to stop anyone using the branch so they only have main available
I’d rather not start a new project but if that’s the only way…
That is the only way, Slim. Branch subdomains, are directly tied to deploys, and you can’t remove either without totally starting over.
Sorry I don’t have better news for you today.
@fool I went ahead a did it. It was relatively painless. I just had to enable the services like identity and copy my env vars.
Plus I totally love the new random URI of “festive hoover”
Sometimes our name generator is brilliant. And sometimes it is very stupid
Glad to hear you got this resolved!
Just to confirm: When we create a branch deploy or deploy preview, we can never take the site down that’s created by that? That branch will always be viewable and accessible at that site URL?
Hey @PopInnovate, yes, that is correct
I have a use case that I believe will likely effect others. All our past Deploy Previews have been indexed by search engines. Since discovering this we have updated our build config to write a Disallow robots.txt for the deploy-preview and branch-preview build contexts.
But every other deploy preview created before this change is still crawled and accessed, appearing in search results and thus diverting traffic from our production site.
Can you step us through your recommended approach to resolving this?
That… should not be happening! Could you please share your Netlify url with us so we can take a look?
Hi Jen can I move this into a DM with you?
hi @digeverything, we don’t generally do support business via DM. what we can do is to unlist this thread, so that no one can see it who doesn’t have the URL. you can also share the API ID with us which is safe to share but no one can really use if they are not a netlify admin.
Hi Perry, no problem.
The API ID is 4db4c5a8-a490-4cb9-9cb4-09e70fa0b9a5 and deploy-preview-79 was the original indexed deployment that brought this to our attention.
Thank you for taking a look.
Hi, @digeverything. I do see you are a member of a paid team type and we do provide private support for all paid team types (as well as for any team type if the issue is billing, login, or something similar).
We have sent you an email for the support ticket. Please reply here if you do not see an email from us about this though.
For other people following along, so far I so see the
x-robots-tag: noindex response header for all deploy preview requests so there is no explanation so far for why a search engine would index that page. If our research does reveal an issue on Netlify’s part, we will update this topic to share that information (minus any private details of course).
I want to note for other following this page that the
robots.txt itself can trigger the indexing in some scenarios.
I’m referring to Google’s documentation on the subject here:
Quoting that page:
Important : For the
noindex directive to be effective, the page must not be blocked by a robots.txt file. If the page is blocked by a robots.txt file, the crawler will never see the
noindex directive, and the page can still appear in search results, for example if other pages link to it.
In other words, even though we include this header, the inclusion of a
robots.txt file will trigger (not prevent) the indexing of the page. If another page links to it and that second page itself is indexed, this page will be indexed even though both the
noindex header and the
robots.txt file are used. This is true for all web hosting and is not specific to Netlify.