diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d0485e8..5f33001 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -6,7 +6,7 @@
 
 ## Filing issues
 
-When [filing an issue](https://golang.org/issue/new), make sure to answer these five questions:
+When [filing an issue](https://go.dev/issue/new), make sure to answer these five questions:
 
 1.  What version of Go are you using (`go version`)?
 2.  What operating system and processor architecture are you using?
@@ -19,7 +19,7 @@
 
 ## Contributing code
 
-Please read the [Contribution Guidelines](https://golang.org/doc/contribute.html)
+Please read the [Contribution Guidelines](https://go.dev/doc/contribute)
 before sending patches.
 
 Unless otherwise noted, the Go source files are distributed under
diff --git a/README.md b/README.md
index 7b161c2..c0da150 100644
--- a/README.md
+++ b/README.md
@@ -13,9 +13,9 @@
 implementing changes to the Go project.
 
 To learn more about Go's origins and development process, see the talks
-[How Go Was Made](https://talks.golang.org/2015/how-go-was-made.slide),
-[The Evolution of Go](https://talks.golang.org/2015/gophercon-goevolution.slide),
-and [Go, Open Source, Community](https://blog.golang.org/open-source)
+[How Go Was Made](https://go.dev/talks/2015/how-go-was-made.slide),
+[The Evolution of Go](https://go.dev/talks/2015/gophercon-goevolution.slide),
+and [Go, Open Source, Community](https://go.dev/blog/open-source)
 from GopherCon 2015.
 
 ## The Proposal Process
@@ -23,7 +23,7 @@
 The proposal process is the process for reviewing a proposal and reaching
 a decision about whether to accept or decline the proposal.
 
-1. The proposal author [creates a brief issue](https://golang.org/issue/new) describing the proposal.\
+1. The proposal author [creates a brief issue](https://go.dev/issue/new) describing the proposal.\
    Note: There is no need for a design document at this point.\
    Note: A non-proposal issue can be turned into a proposal by simply adding the proposal label.\
    Note: [Language changes](#language-changes) should follow a separate [template](go2-language-changes.md)
@@ -97,7 +97,7 @@
 
 Programs written for Go version 1.x must continue to compile and work with
 future versions of Go 1.
-The [Go 1 compatibility document](https://golang.org/doc/go1compat) describes
+The [Go 1 compatibility document](https://go.dev/doc/go1compat) describes
 the promise we have made to Go users for the future of Go 1.x.
 Any proposed change must not break this promise.
 
@@ -105,7 +105,7 @@
 
 In 2018 we started a Go 2 process during which we may change the
 language, as described on [the Go
-blog](https://blog.golang.org/go2-here-we-come).
+blog](https://go.dev/blog/go2-here-we-come).
 Language changes should follow the proposal process described here.
 As explained in the blog entry, language change proposals should
 
@@ -114,8 +114,8 @@
 - come with a clear and well-understood solution.
 
 Proposals should follow the [Go 2 template](go2-language-changes.md).
-See the [Go 2 review minutes](https://golang.org/issue/33892)
-and the [release notes](https://golang.org/doc/devel/release.html) for
+See the [Go 2 review minutes](https://go.dev/issue/33892)
+and the [release notes](https://go.dev/doc/devel/release) for
 examples of recent language changes.
 
 ### Design Documents
@@ -126,7 +126,7 @@
 where `NNNN` is the GitHub issue number and `shortname` is a short name
 (a few dash-separated words at most).
 Clone this repository with `git clone https://go.googlesource.com/proposal`
-and follow the usual [Gerrit workflow for Go](https://golang.org/doc/contribute.html#Code_review).
+and follow the usual [Gerrit workflow for Go](https://go.dev/doc/contribute#review).
 
 - The design doc should follow [the template](design/TEMPLATE.md).
 
@@ -137,7 +137,7 @@
 
 - For ease of review with Gerrit, design documents should be wrapped around the
 80 column mark.
-[Each sentence should start on a new line](http://rhodesmill.org/brandon/2012/one-sentence-per-line/)
+[Each sentence should start on a new line](https://rhodesmill.org/brandon/2012/one-sentence-per-line/)
 so that comments can be made accurately and the diff kept shorter.
   - In Emacs, loading `fill.el` from this directory will make `fill-paragraph` format text this way.
 
@@ -172,7 +172,7 @@
 advanced to the next step (by marking the proposal accepted
 or declined or by asking for a design doc).
 
-Minutes are posted to [golang.org/s/proposal-minutes](https://golang.org/s/proposal-minutes)
+Minutes are posted to [go.dev/s/proposal-minutes](https://go.dev/s/proposal-minutes)
 after the conclusion of the weekly meeting, so that anyone
 interested in which proposals are under active consideration
 can follow that issue.
@@ -200,7 +200,7 @@
 Holding proposals in Incoming until attention can be devoted to them
 (at which they move to Active, and then onward) ensures that
 progress is made moving active proposals out to Accepted or Declined,
-so we avoid [receive livelock](http://www.news.cs.nyu.edu/~jinyang/sp09/readings/mogul96usenix.pdf),
+so we avoid [receive livelock](https://www.news.cs.nyu.edu/~jinyang/sp09/readings/mogul96usenix.pdf),
 in which accepting new work prevents finishing old work.
 
 #### Active
@@ -347,4 +347,4 @@
 delay while their message is held for moderation.)
 
 To learn about contributing to Go in general, see the
-[contribution guidelines](https://golang.org/doc/contribute.html).
+[contribution guidelines](https://go.dev/doc/contribute).