updated links to the new services pages

website/content/api-docs/agent/service.mdx

@@ -170,13 +170,20 @@ The table below shows this endpoint's support for
 
 ### Sample Request
 
+The following example request calls the `web-sidecar-proxy` service:
+
 ```shell-session
 $ curl \
     http://127.0.0.1:8500/v1/agent/service/web-sidecar-proxy
 ```
 
 ### Sample Response
 
+The response contains the fields specified in the [service
+definition](/consul/docs/services/configuration/services-configuration-reference), but it includes an extra `ContentHash` field that contains the [hash-based blocking
+query](/consul/api-docs/features/blocking#hash-based-blocking-queries) hash for the result. The
+same hash is also present in `X-Consul-ContentHash`.
+
 ```json
 {
   "Kind": "connect-proxy",
@@ -227,12 +234,6 @@ $ curl \
 }
 ```
 
-The response has the same structure as the [service
-definition](/consul/docs/discovery/services) with one extra field `ContentHash` which
-contains the [hash-based blocking
-query](/consul/api-docs/features/blocking#hash-based-blocking-queries) hash for the result. The
-same hash is also present in `X-Consul-ContentHash`.
-
 ## Get local service health
 
 Retrieve an aggregated state of service(s) on the local agent by name.
@@ -599,21 +600,18 @@ The corresponding CLI command is [`consul services register`](/consul/commands/s
 
 ### JSON Request Body Schema
 
-Note that this endpoint, unlike most also [supports `snake_case`](/consul/docs/discovery/services#service-definition-parameter-case)
-service definition keys for compatibility with the config file format.
+The `/agent/service/register` endpoint supports camel case and _snake case_ for service definition keys. Snake case is a convention in which keys with two or more words have underscores between them. Snake case ensures compatibility with the agent configuration file format.
 
 - `Name` `(string: <required>)` - Specifies the logical name of the service.
   Many service instances may share the same logical service name. We recommend using
-  [valid DNS labels](https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames)
-  for [compatibility with external DNS](/consul/docs/discovery/services#service-and-tag-names-with-dns).
+  valid DNS labels for service definition names. Refer to the Internet Engineering Task Force's [RFC 1123](https://datatracker.ietf.org/doc/html/rfc1123#page-72) for additional information. Service names that conform to standard usage ensures compatibility with external DNSs. Refer to [Services Configuration Reference](/consul/docs/services/configuration/services-configuration-reference#name) for additional information.
 
 - `ID` `(string: "")` - Specifies a unique ID for this service. This must be
   unique per _agent_. This defaults to the `Name` parameter if not provided.
 
 - `Tags` `(array<string>: nil)` - Specifies a list of tags to assign to the
-  service. These tags can be used for later filtering and are exposed via the APIs.
-  We recommend using [valid DNS labels](https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames)
-  for [compatibility with external DNS](/consul/docs/discovery/services#service-and-tag-names-with-dns)
+  service. Tags enable you to filter when querying for the services and are exposed in Consul APIs. We recommend using
+  valid DNS labels for tags. Refer to the Internet Engineering Task Force's [RFC 1123](https://datatracker.ietf.org/doc/html/rfc1123#page-72) for additional information. Tags that conform to standard usage ensures compatibility with external DNSs. Refer to [Services Configuration Reference](/consul/docs/services/configuration/services-configuration-reference#tags) for additional information.
 
 - `Address` `(string: "")` - Specifies the address of the service. If not
   provided, the agent's address is used as the address for the service during
@@ -676,19 +674,15 @@ service definition keys for compatibility with the config file format.
   service's port _and_ the tags would revert to the original value and all
   modifications would be lost.
 
-- `Weights` `(Weights: nil)` - Specifies weights for the service. Please see the
-  [service documentation](/consul/docs/discovery/services) for more information about
-  weights. If this field is not provided weights will default to
+- `Weights` `(Weights: nil)` - Specifies weights for the service. Refer to 
+  [Services Configuration Reference](/consul/docs/services/configuraiton/services-configuration-reference#weights) for additional information. Default is
   `{"Passing": 1, "Warning": 1}`.
 
-  It is important to note that this applies only to the locally registered
-  service. If you have multiple nodes all registering the same service their
-  `EnableTagOverride` configuration and all other service configuration items
-  are independent of one another. Updating the tags for the service registered
-  on one node is independent of the same service (by name) registered on
-  another node. If `EnableTagOverride` is not specified the default value is
+  Weights only apply to the locally registered service. 
+  If multiple nodes register the same service, each node implements `EnableTagOverride` and other service configuration items independently. Updating the tags for the service registered
+  on one node does not necessarily update the same tags on services with the same name registered on another node. If `EnableTagOverride` is not specified the default value is
   `false`. See [anti-entropy syncs](/consul/docs/architecture/anti-entropy) for
-  more info.
+  additional information.
 
 #### Connect Structure
 

website/content/api-docs/catalog.mdx

@@ -55,15 +55,16 @@ The table below shows this endpoint's support for
 - `NodeMeta` `(map<string|string>: nil)` - Specifies arbitrary KV metadata
   pairs for filtering purposes.
 
-- `Service` `(Service: nil)` - Specifies to register a service. If `ID` is not
-  provided, it will be defaulted to the value of the `Service.Service` property.
-  Only one service with a given `ID` may be present per node. We recommend using
-  [valid DNS labels](https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames)
-  for service definition names for [compatibility with external DNS](/consul/docs/discovery/services#service-and-tag-names-with-dns).
-  The service `Tags`, `Address`, `Meta`, and `Port` fields are all optional. For more
-  information about these fields and the implications of setting them,
-  see the [Service - Agent API](/consul/api-docs/agent/service) page
-  as registering services differs between using this or the Services Agent endpoint.
+- `Service` `(Service: nil)` - Contains an object the specifies the service to register. The the `Service.Service` field is required. If `Service.ID` is not provided, the default is the `Service.Service`.
+  You can only specify one service with a given `ID` per node. We recommend using
+  valid DNS labels for service definition names. Refer to the Internet Engineering Task Force's [RFC 1123](https://datatracker.ietf.org/doc/html/rfc1123#page-72) for additional information. Service names that conform to standard usage ensures compatibility with external DNSs. Refer to [Services Configuration Reference](/consul/docs/services/configuration/services-configuration-reference#name) for additional information.
+  The following fields are optional: 
+    - `Tags` 
+    - `Address` 
+    - `Meta` 
+    - `Port`  
+
+  For additional information configuring services, refer to [Service - Agent API](/consul/api-docs/agent/service). The `/catalog` endpoint had different behaviors than the `/services` endpoint.
 
 - `Check` `(Check: nil)` - Specifies to register a check. The register API
   manipulates the health check entry in the Catalog, but it does not setup the

website/content/commands/services/deregister.mdx

@@ -13,23 +13,19 @@ Corresponding HTTP API Endpoint: [\[PUT\] /v1/agent/service/deregister/:service_
 
 The `services deregister` command deregisters a service with the local agent.
 Note that this command can only deregister services that were registered
-with the agent specified (defaults to the local agent) and is meant to
-be paired with `services register`.
+with the agent specified and is intended to be paired with `services register`. 
+By default, the command deregisters services on the local agent. 
 
-This is just one method for service deregistration. If the service was
-registered with a configuration file, then deleting that file and
-[reloading](/consul/commands/reload) Consul is the correct method to
-deregister. See [Service Definition](/consul/docs/discovery/services) for more
-information about registering services generally.
+We recommend deregistering services registered with a configuration file by deleting the file and [reloading](/consul/commands/reload) Consul. Refer to [Services Overview](/consul/docs/services/services) for additional information about services.
 
-The table below shows this command's [required ACLs](/consul/api-docs/api-structure#authentication). Configuration of
-[blocking queries](/consul/api-docs/features/blocking) and [agent caching](/consul/api-docs/features/caching)
-are not supported from commands, but may be from the corresponding HTTP endpoint.
+The following table shows the [ACLs](/consul/api-docs/api-structure#authentication) required to run the `consul services deregister` command: 
 
 | ACL Required    |
 | --------------- |
 | `service:write` |
 
+You cannot use the Consul command line to configure [blocking queries](/consul/api-docs/features/blocking) and [agent caching](/consul/api-docs/features/caching), you can configure them from the corresponding HTTP endpoint.
+
 ## Usage
 
 Usage: `consul services deregister [options] [FILE...]`

website/content/commands/services/register.mdx

@@ -14,24 +14,16 @@ Corresponding HTTP API Endpoint: [\[PUT\] /v1/agent/service/register](/consul/ap
 The `services register` command registers a service with the local agent.
 This command returns after registration and must be paired with explicit
 service deregistration. This command simplifies service registration from
-scripts, in dev mode, etc.
+scripts. Refer to [Register Services and Health Checks](/consul/docs/services/usage/register-services-checks) for information about other service registeration methods. 
 
-This is just one method of service registration. Services can also be
-registered by placing a [service definition](/consul/docs/discovery/services)
-in the Consul agent configuration directory and issuing a
-[reload](/consul/commands/reload). This approach is easiest for
-configuration management systems that other systems that have access to
-the configuration directory. Clients may also use the
-[HTTP API](/consul/api-docs/agent/service) directly.
-
-The table below shows this command's [required ACLs](/consul/api-docs/api-structure#authentication). Configuration of
-[blocking queries](/consul/api-docs/features/blocking) and [agent caching](/consul/api-docs/features/caching)
-are not supported from commands, but may be from the corresponding HTTP endpoint.
+The following table shows the [ACLs](/consul/api-docs/api-structure#authentication) required to use the `consul services register` command:
 
 | ACL Required    |
 | --------------- |
 | `service:write` |
 
+You cannot use the Consul command line to configure [blocking queries](/consul/api-docs/features/blocking) and [agent caching](/consul/api-docs/features/caching), you can configure them from the corresponding HTTP endpoint.
+
 ## Usage
 
 Usage: `consul services register [options] [FILE...]`
@@ -65,9 +57,7 @@ The flags below should only be set if _no arguments_ are given. If no
 arguments are given, the flags below can be used to register a single
 service.
 
-Note that the behavior of each of the fields below is exactly the same
-as when constructing a standard [service definition](/consul/docs/discovery/services).
-Please refer to that documentation for full details.
+The following fields specify identical parameters in a standard service definition file. Refer to [Services Configuration Reference](/consul/docs/services/configuration/services-configuration-reference) for details about each configuration option.
 
 - `-id` - The ID of the service. This will default to `-name` if not set.
 

website/content/docs/agent/config/config-files.mdx

@@ -7,6 +7,10 @@ description: >-
 
 # Agents Configuration File Reference ((#configuration_files))
 
+This topic describes the parameters for configuring Consul agents. For information about how to start Consul agents, refer to [Starting the Consul Agent](/consul/docs/agent#starting-the-consul-agent). 
+
+## Overview
+
 You can create one or more files to configure the Consul agent on startup. We recommend
 grouping similar configurations into separate files, such as ACL parameters, to make it
 easier to manage configuration changes. Using external files may be easier than
@@ -18,13 +22,6 @@ easily readable and editable by both humans and computers. JSON formatted
 configuration consists of a single JSON object with multiple configuration keys
 specified within it.
 
-Configuration files are used for more than just setting up the agent.
-They are also used to provide check and service definitions that
-announce the availability of system servers to the rest of the cluster.
-These definitions are documented separately under [check configuration](/consul/docs/discovery/checks) and
-[service configuration](/consul/docs/discovery/services) respectively. Service and check
-definitions support being updated during a reload.
-
 <CodeTabs heading="Example Configuration File">
 
 ```hcl
@@ -66,13 +63,25 @@ telemetry {
 
 </CodeTabs>
 
-# Configuration Key Reference ((#config_key_reference))
+### Time-to-live values 
+
+Consul uses the Go `time` package too parse all time-to-live (TTL) values used in Consul agent configuration files. Specify integer and float values as a string and include one or more of the following units of time:
+
+- `ns`
+- `us` 
+- `µs` 
+- `ms`
+- `s` 
+- `m`
+- `h`
+
+Examples: 
+
+- `'300ms'` 
+- `'1.5h'` 
+- `'2h45m'`
 
--> **Note:** All the TTL values described below are parsed by Go's `time` package, and have the following
-[formatting specification](https://golang.org/pkg/time/#ParseDuration): "A
-duration string is a possibly signed sequence of decimal numbers, each with
-optional fraction and a unit suffix, such as '300ms', '-1.5h' or '2h45m'.
-Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'."
+Refer to the [formatting specification](https://golang.org/pkg/time/#ParseDuration) for additional information. 
 
 ## General
 
@@ -914,10 +923,9 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'."
     - `agent_master` ((#acl_tokens_agent_master)) **Renamed in Consul 1.11 to
       [`acl.tokens.agent_recovery`](#acl_tokens_agent_recovery).**
 
-    - `config_file_service_registration` ((#acl_tokens_config_file_service_registration)) - The ACL
-      token this agent uses to register services and checks from [service
-      definitions](/consul/docs/discovery/services) and [check definitions](/consul/docs/discovery/checks) found
-      in configuration files or in configuration fragments passed to the agent using the `-hcl`
+    - `config_file_service_registration` ((#acl_tokens_config_file_service_registration)) - Specifies the ACL
+      token the agent uses to register services and checks from [service](/consul/docs/services/usage/define-services) and [check](/consul/docs/usage/checks) definitions 
+      specified in configuration files or fragments passed to the agent using the `-hcl`
       flag.
 
       If the `token` field is defined in the service or check definition, then that token is used to

website/content/docs/architecture/anti-entropy.mdx

@@ -117,8 +117,7 @@ the source of truth for tag information. For example, the Redis
 database and its monitoring service Redis Sentinel have this kind of
 relationship. Redis instances are responsible for much of their
 configuration, but Sentinels determine whether the Redis instance is a
-primary or a secondary. Using the Consul service configuration item
-[enable_tag_override](/consul/docs/discovery/services) you can instruct the
-Consul agent on which the Redis database is running to NOT update the
-tags during anti-entropy synchronization. For more information see
-[Services](/consul/docs/discovery/services#enable-tag-override-and-anti-entropy) page.
+primary or a secondary. Enable the 
+[`enable_tag_override`](/consul/docs/services/configuration/services-configuration-reference#enable_tag_override) parameter in your service definition file to tell the Consul agent where the Redis database is running to bypass
+tags during anti-entropy synchronization. Refer to 
+[Modify anti-entropy synchronozation](/consul/docs/services/usage/define-services#modify-anti-entropy-synchronization) for additional information.

website/content/docs/architecture/scale.mdx

@@ -236,7 +236,7 @@ Several factors influence Consul performance at scale when used primarily for it
 - Rate of catalog updates, which is affected by the following events:
     - A service instance’s health check status changes
     - A service instance’s node loses connectivity to Consul servers
-    - The contents of the [service definition file](/consul/docs/discovery/services#service-definition) changes
+    - The contents of the [service definition file](/consul/docs/services/configuration/services-configuration-reference) changes
     - Service instances are registered or deregistered
     - Orchestrators such as Kubernetes or Nomad move a service to a new node
 

website/content/docs/connect/configuration.mdx

@@ -9,14 +9,11 @@ description: >-
 
 There are many configuration options exposed for Consul service mesh. The only option
 that must be set is the `connect.enabled` option on Consul servers to enable Consul service mesh.
-All other configurations are optional and have reasonable defaults.
+All other configurations are optional and have defaults suitable for many environments.
 
-Consul Connect is the component shipped with Consul that enables service mesh functionality. The terms _Consul Connect_ and _Consul service mesh_ are used interchangeably throughout this documentation. 
+The terms _Consul Connect_ and _Consul service mesh_ are used interchangeably throughout this documentation. 
 
--> **Tip:** Service mesh is enabled by default when running Consul in
-dev mode with `consul agent -dev`.
-
-## Agent Configuration
+## Agent configuration
 
 Begin by enabling Connect for your Consul
 cluster. By default, Connect is disabled. Enabling Connect requires changing
@@ -75,18 +72,12 @@ automatically ensure complete security. Please read the [Connect production
 tutorial](/consul/tutorials/developer-mesh/service-mesh-production-checklist) to understand the additional steps
 needed for a secure deployment.
 
-## Centralized Proxy and Service Configuration
-
-To account for common Connect use cases where you have many instances of the
-same service, and many colocated sidecar proxies, Consul allows you to customize
-the settings for all of your proxies or all the instances of a given service at
-once using [Configuration Entries](/consul/docs/agent/config-entries).
+## Centralized proxy and service configuration
 
-You can override centralized configurations for individual proxy instances in
-their
+If your network contains many instances of the same service and many colocated sidecar proxies, you can specify global settings for proxies or services in [Configuration Entries](/consul/docs/agent/config-entries). You can override the centralized configurations for individual proxy instances in their
 [sidecar service definitions](/consul/docs/connect/registration/sidecar-service),
 and the default protocols for service instances in their [service
-registrations](/consul/docs/discovery/services).
+definitions](/consul/docs/services/usage/define-services).
 
 ## Schedulers