diff --git a/content/en/docs/concepts/_index.md b/content/en/docs/concepts/_index.md
index 2106ae21cb9df..0cb970fd66e09 100644
--- a/content/en/docs/concepts/_index.md
+++ b/content/en/docs/concepts/_index.md
@@ -24,9 +24,9 @@ Once you've set your desired state, the *Kubernetes Control Plane* makes the clu
   * **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master.
   * **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node.
 
-## Kubernetes Objects
+## Kubernetes objects
 
-Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes Objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) for more details.
+Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) for more details.
 
 The basic Kubernetes objects include:
 
@@ -35,7 +35,7 @@ The basic Kubernetes objects include:
 * [Volume](/docs/concepts/storage/volumes/)
 * [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
 
-Kubernetes also contains higher-level abstractions that rely on [Controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include:
+Kubernetes also contains higher-level abstractions that rely on [controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include:
 
 * [Deployment](/docs/concepts/workloads/controllers/deployment/)
 * [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
diff --git a/content/en/docs/concepts/architecture/controller.md b/content/en/docs/concepts/architecture/controller.md
index fe8965f3e2873..e5bee1d0a52a7 100644
--- a/content/en/docs/concepts/architecture/controller.md
+++ b/content/en/docs/concepts/architecture/controller.md
@@ -26,7 +26,7 @@ closer to the desired state, by turning equipment on or off.
 ## Controller pattern
 
 A controller tracks at least one Kubernetes resource type.
-These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
 have a spec field that represents the desired state. The
 controller(s) for that resource are responsible for making the current
 state come closer to that desired state.
diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index e9e7069fce98b..d26d3573801c5 100644
--- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -37,7 +37,7 @@ On their own, custom resources simply let you store and retrieve structured data
 When you combine a custom resource with a *custom controller*, custom resources
 provide a true _declarative API_.
 
-A [declarative API](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects)
+A [declarative API](/docs/concepts/overview/kubernetes-api/)
 allows you to _declare_ or specify the desired state of your resource and tries to
 keep the current state of Kubernetes objects in sync with the desired state.
 The controller interprets the structured data as a record of the user's
diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index f0bac7e4cbd00..b6c09be817bf2 100644
--- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -12,9 +12,9 @@ This page explains how Kubernetes objects are represented in the Kubernetes API,
 {{% /capture %}}
 
 {{% capture body %}}
-## Understanding Kubernetes Objects
+## Understanding Kubernetes objects {#kubernetes-objects}
 
-*Kubernetes Objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
+*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
 
 * What containerized applications are running (and on which nodes)
 * The resources available to those applications
@@ -33,7 +33,7 @@ For example, a Kubernetes Deployment is an object that can represent an applicat
 
 For more information on the object spec, status, and metadata, see the [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
 
-### Describing a Kubernetes Object
+### Describing a Kubernetes object
 
 When you create an object in Kubernetes, you must provide the object spec that describes its desired state, as well as some basic information about the object (such as a name). When you use the Kubernetes API to create the object (either directly or via `kubectl`), that API request must include that information as JSON in the request body. **Most often, you provide the information to `kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API request.
 
@@ -51,7 +51,7 @@ kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
 
 The output is similar to this:
 
-```shell
+```
 deployment.apps/nginx-deployment created
 ```
 
@@ -65,14 +65,15 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to
 * `spec` - What state you desire for the object
 
 The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) can help you find the spec format for all of the objects you can create using Kubernetes.
-For example, the `spec` format for a `Pod` can be found
-[here](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core),
-and the `spec` format for a `Deployment` can be found
-[here](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
+For example, the `spec` format for a Pod can be found in
+[PodSpec v1 core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core),
+and the `spec` format for a Deployment can be found
+[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
 
 {{% /capture %}}
 
 {{% capture whatsnext %}}
+* [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts
 * Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
 * Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
 {{% /capture %}}
diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md
index 5a61bec8c0223..c18559238d966 100644
--- a/content/en/docs/reference/using-api/api-concepts.md
+++ b/content/en/docs/reference/using-api/api-concepts.md
@@ -18,7 +18,7 @@ updating, and deleting primary resources via the standard HTTP verbs (POST, PUT,
 
 ## Standard API terminology
 
-Most Kubernetes API resource types are "objects" - they represent a concrete instance of a concept on the cluster, like a pod or namespace. A smaller number of API resource types are "virtual" - they often represent operations rather than objects, such as a permission check (use a POST with a JSON-encoded body of `SubjectAccessReview` to the `subjectaccessreviews` resource). All objects will have a unique name to allow idempotent creation and retrieval, but virtual resource types may not have unique names if they are not retrievable or do not rely on idempotency.
+Most Kubernetes API resource types are [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects): they represent a concrete instance of a concept on the cluster, like a pod or namespace. A smaller number of API resource types are "virtual" - they often represent operations rather than objects, such as a permission check (use a POST with a JSON-encoded body of `SubjectAccessReview` to the `subjectaccessreviews` resource). All objects will have a unique name to allow idempotent creation and retrieval, but virtual resource types may not have unique names if they are not retrievable or do not rely on idempotency.
 
 Kubernetes generally leverages standard RESTful terminology to describe the API concepts: