Code change:
Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented. May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Related discussion:
text: --build-arg HUGO_VERSION=$(HUGO_VERSION) container-build: module-check <del> $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify" </del> <ins> $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify --environment development" </ins> container-serve: module-check ## Boot the development server using container. Run `make container-image` before this. <del> $(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir </del> <ins> $(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir </ins> test-examples: scripts/test_examples.sh install