clarify the compatibility dates page (#18260)

Co-authored-by: Greg Brimble <[email protected]>

Author: vicb

src/content/docs/workers/configuration/compatibility-dates.mdx

@@ -12,14 +12,14 @@ The compatibility date and flags are how you, as a developer, opt into these run
 
 ## Setting compatibility date
 
-When you start your project, you should always set `compatibility_date` to the current date. You should occasionally update the `compatibility_date` field. When updating, you should refer to this page to find out what has changed, and you should be careful to test your Worker to see if the changes affect you, updating your code as necessary. The new compatibility date takes effect when you next run the [`npx wrangler deploy`](/workers/wrangler/commands/#deploy) command.
+When you start your project, you should always set `compatibility_date` to the current date. You should occasionally update the `compatibility_date` field. When updating, you should refer to the [compatibility flags](/workers/configuration/compatibility-flags) page to find out what has changed, and you should be careful to test your Worker to see if the changes affect you, updating your code as necessary. The new compatibility date takes effect when you next run the [`npx wrangler deploy`](/workers/wrangler/commands/#deploy) command.
 
 There is no need to update your `compatibility_date` if you do not want to. The Workers runtime will support old compatibility dates forever. If, for some reason, Cloudflare finds it is necessary to make a change that will break live Workers, Cloudflare will actively contact affected developers. That said, Cloudflare aims to avoid this if at all possible.
 
 However, even though you do not need to update the `compatibility_date` field, it is a good practice to do so for two reasons:
 
 1. Sometimes, new features can only be made available to Workers that have a current `compatibility_date`. To access the latest features, you need to stay up-to-date.
-2. Generally, other than this page, the Workers documentation may only describe the current `compatibility_date`, omitting information about historical behavior. If your Worker uses an old `compatibility_date`, you will need to continuously refer to this page in order to check if any of the APIs you are using have changed.
+2. Generally, other than the [compatibility flags](/workers/configuration/compatibility-flags) page, the Workers documentation may only describe the current `compatibility_date`, omitting information about historical behavior. If your Worker uses an old `compatibility_date`, you will need to continuously refer to the compatibility flags page in order to check if any of the APIs you are using have changed.
 
 #### Via Wrangler
 
@@ -34,7 +34,7 @@ compatibility_date = "2022-04-05"
 
 When a Worker is created through the Cloudflare Dashboard, the compatibility date is automatically set to the current date.
 
-The compatibility date cannot be updated on the Cloudflare Dashboard at this time.
+The compatibility date can be updated in the Workers settings on the [Cloudflare dashboard](https://dash.cloudflare.com/).
 
 #### Via the Cloudflare API
 

src/content/docs/workers/configuration/compatibility-flags.mdx

@@ -31,7 +31,7 @@ compatibility_flags = [ "formdata_parser_supports_files" ]
 
 #### Via the Cloudflare Dashboard
 
-Compatibility flags cannot be set or updated on the Cloudflare Dashboard at this time.
+Compatibility flags can be updated in the Workers settings on the [Cloudflare dashboard](https://dash.cloudflare.com/).
 
 #### Via the Cloudflare API