diff --git a/content/c-go-cgo.article b/content/c-go-cgo.article
index d0e9976..71773b9 100644
--- a/content/c-go-cgo.article
+++ b/content/c-go-cgo.article
@@ -104,6 +104,4 @@
 
 The [[http://golang.org/cmd/cgo/][cgo command]] documentation has more detail about the C pseudo-package and the build process. The [[http://golang.org/misc/cgo/][cgo examples]] in the Go tree demonstrate more advanced concepts.
 
-For a simple, idiomatic example of a cgo-based package, see Russ Cox's [[http://code.google.com/p/gosqlite/source/browse/sqlite/sqlite.go][gosqlite]]. Also, the Go Project Dashboard lists [[https://godashboard.appspot.com/project?tag=cgo][several other cgo packages]].
-
 Finally, if you're curious as to how all this works internally, take a look at the introductory comment of the runtime package's [[https://golang.org/src/runtime/cgocall.go][cgocall.go]].
diff --git a/content/error-handling-and-go.article b/content/error-handling-and-go.article
index efa6c46..6535c0b 100644
--- a/content/error-handling-and-go.article
+++ b/content/error-handling-and-go.article
@@ -131,7 +131,7 @@
 
 In Go, error handling is important. The language's design and conventions encourage you to explicitly check for errors where they occur (as distinct from the convention in other languages of throwing exceptions and sometimes catching them). In some cases this makes Go code verbose, but fortunately there are some techniques you can use to minimize repetitive error handling.
 
-Consider an [[http://code.google.com/appengine/docs/go/][App Engine]] application with an HTTP handler that retrieves a record from the datastore and formats it with a template.
+Consider an [[https://cloud.google.com/appengine/docs/go/][App Engine]] application with an HTTP handler that retrieves a record from the datastore and formats it with a template.
 
 	func init() {
 	    http.HandleFunc("/view", viewRecord)
diff --git a/content/go-fmt-your-code.article b/content/go-fmt-your-code.article
index 86f7dc1..068d9ae 100644
--- a/content/go-fmt-your-code.article
+++ b/content/go-fmt-your-code.article
@@ -52,7 +52,7 @@
 
 where both pattern and replacement are valid Go expressions. In the pattern, single-character lowercase identifiers serve as wildcards matching arbitrary sub-expressions, and those expressions are substituted for the same identifiers in the replacement.
 
-For example, this[[https://code.google.com/p/go/source/detail?r=ae4e014e0b77][ recent change]] to the Go core rewrote some uses of [[http://golang.org/pkg/bytes/#Compare][bytes.Compare]] to use the more efficient [[http://golang.org/pkg/bytes/#Equal][bytes.Equal]]. The contributor made the change using just two gofmt invocations:
+For example, this[[https://golang.org/cl/7038051][ recent change]] to the Go core rewrote some uses of [[http://golang.org/pkg/bytes/#Compare][bytes.Compare]] to use the more efficient [[http://golang.org/pkg/bytes/#Equal][bytes.Equal]]. The contributor made the change using just two gofmt invocations:
 
 	 gofmt -r 'bytes.Compare(a, b) == 0 -> bytes.Equal(a, b)'
 	 gofmt -r 'bytes.Compare(a, b) != 0 -> !bytes.Equal(a, b)'
diff --git a/content/organizing-go-code.article b/content/organizing-go-code.article
index 17e8831..147bee2 100644
--- a/content/organizing-go-code.article
+++ b/content/organizing-go-code.article
@@ -22,7 +22,7 @@
 
 An import path is the string with which users import a package. It specifies the directory (relative to `$GOROOT/src/pkg` or `$GOPATH/src`) in which the package's source code resides.
 
-Import paths should be globally unique, so use the path of your source repository as its base. For instance, the `websocket` package from the `go.net` sub-repository has an import path of `"golang.org/x/net/websocket"`. The Go project owns the path `"code.google.com/p/go"`, so that path cannot be used by another author for a different package. Because the repository URL and import path are one and the same, the `go`get` command can fetch and install the package automatically.
+Import paths should be globally unique, so use the path of your source repository as its base. For instance, the `websocket` package from the `go.net` sub-repository has an import path of `"golang.org/x/net/websocket"`. The Go project owns the path `"github.com/golang"`, so that path cannot be used by another author for a different package. Because the repository URL and import path are one and the same, the `go`get` command can fetch and install the package automatically.
 
 If you don't use a hosted source repository, choose some unique prefix such as a domain, company, or project name. As an example, the import path of all Google's internal Go code starts with the string `"google"`.
 
diff --git a/content/package-names.article b/content/package-names.article
index f0429a2..967f02c 100644
--- a/content/package-names.article
+++ b/content/package-names.article
@@ -150,7 +150,7 @@
 packages in different directories can have the same name.
 For example,
 [[https://golang.org/pkg/runtime/pprof][runtime/pprof]] provides profiling data
-in the format expected by the [[https://code.google.com/p/gperftools][pprof]]
+in the format expected by the [[https://github.com/google/pprof][pprof]]
 profiling tool, while [[https://golang.org/pkg/net/http/pprof][net/http/pprof]]
 provides HTTP endpoints to present profiling data in this format.
 Client code uses the package path to import the package, so there is no
diff --git a/content/race-detector.article b/content/race-detector.article
index 652830d..bf3ce20 100644
--- a/content/race-detector.article
+++ b/content/race-detector.article
@@ -22,11 +22,11 @@
 with 64-bit x86 processors.
 
 The race detector is based on the C/C++
-[[https://code.google.com/p/thread-sanitizer/][ThreadSanitizer runtime library]],
+[[https://github.com/google/sanitizers][ThreadSanitizer runtime library]],
 which has been used to detect many errors in Google's internal code base and in
 [[http://www.chromium.org/][Chromium]].
 The technology was integrated with Go in September 2012; since then it has detected
-[[https://code.google.com/p/go/issues/list?can=1&q=ThreadSanitizer][42 races]]
+[[https://github.com/golang/go/issues?utf8=%E2%9C%93&q=ThreadSanitizer][42 races]]
 in the standard library. It is now part of our continuous build process,
 where it continues to catch race conditions as they arise.
 
@@ -37,7 +37,7 @@
 with code that records when and how the memory was accessed, while the runtime
 library watches for unsynchronized accesses to shared variables.
 When such "racy" behavior is detected, a warning is printed.
-(See [[https://code.google.com/p/thread-sanitizer/wiki/Algorithm][this article]]
+(See [[https://github.com/google/sanitizers/wiki/ThreadSanitizerAlgorithm][this article]]
 for the details of the algorithm.)
 
 Because of its design, the race detector can detect race conditions only when
@@ -165,22 +165,22 @@
 	writer.ReadFrom(reader)
 
 We
-[[https://code.google.com/p/go/source/detail?r=13faa632ba3a#][added a ReadFrom method]]
+[[https://golang.org/cl/4817041][added a ReadFrom method]]
 to Discard's underlying type, which has an internal buffer that is shared
 between all its users.
 We knew this was theoretically a race condition, but since all writes to the
 buffer should be thrown away we didn't think it was important.
 
 When the race detector was implemented it immediately
-[[https://code.google.com/p/go/issues/detail?id=3970][flagged this code]] as racy.
+[[https://golang.org/issue/3970][flagged this code]] as racy.
 Again, we considered that the code might be problematic, but decided that the
 race condition wasn't "real".
 To avoid the "false positive" in our build we implemented
-[[https://code.google.com/p/go/source/detail?r=1e55cf10aa4f][a non-racy version]]
+[[https://golang.org/cl/6624059][a non-racy version]]
 that is enabled only when the race detector is running.
 
-But a few months later [[http://bradfitz.com/][Brad]] encountered a
-[[https://code.google.com/p/go/issues/detail?id=4589][frustrating and strange bug]].
+But a few months later [[https://bradfitz.com/][Brad]] encountered a
+[[https://golang.org/issue/4589][frustrating and strange bug]].
 After a few days of debugging, he narrowed it down to a real race condition
 caused by `ioutil.Discard`.
 
@@ -232,7 +232,7 @@
 	}
 
 The bug was finally
-[[https://code.google.com/p/go/source/detail?r=4b61f121966b][fixed]]
+[[https://golang.org/cl/7011047][fixed]]
 by giving a unique buffer to each use of `ioutil.Discard`, eliminating the race
 condition on the shared buffer.