[D1] Fixing broken links for D1. (#19202)

* Fixing broken links for D1.

* Update src/content/docs/d1/observability/billing.mdx

Co-authored-by: hyperlint-ai[bot] <154288675+hyperlint-ai[bot]@users.noreply.github.com>

---------

Co-authored-by: hyperlint-ai[bot] <154288675+hyperlint-ai[bot]@users.noreply.github.com>

Author: Oxyjun

src/content/docs/d1/best-practices/import-export-data.mdx

@@ -107,7 +107,7 @@ You can then follow the steps to [import an existing database](#import-an-existi
 
 ## Export an existing D1 database
 
-In addition to importing existing SQLite databases, you might want to export a D1 database for local development or testing. You can export a D1 database to a `.sql` file using [wrangler d1 export](/workers/wrangler/commands/#export) and then execute (import) with `d1 execute --file`.
+In addition to importing existing SQLite databases, you might want to export a D1 database for local development or testing. You can export a D1 database to a `.sql` file using [wrangler d1 export](/workers/wrangler/commands/#d1-export) and then execute (import) with `d1 execute --file`.
 
 To export full D1 database schema and data:
 

src/content/docs/d1/observability/billing.mdx

@@ -8,7 +8,7 @@ sidebar:
 
 D1 exposes analytics to track billing metrics (rows read, rows written, and total storage) across all databases in your account.
 
-The metrics displayed in the [Cloudflare dashboard](https://dash.cloudflare.com/) are sourced from Cloudflare’s [GraphQL Analytics API](/analytics/graphql-api/). You can access the metrics [programmatically](#query-via-the-graphql-api) via GraphQL or HTTP client.
+The metrics displayed in the [Cloudflare dashboard](https://dash.cloudflare.com/) are sourced from Cloudflare's [GraphQL Analytics API](/analytics/graphql-api/). You can access the metrics [programmatically](/d1/observability/metrics-analytics/#query-via-the-graphql-api) via GraphQL or HTTP client.
 
 ## View metrics in the dashboard
 
@@ -24,7 +24,7 @@ Note that billable usage history is stored for a maximum of 30 days.
 
 ## Billing Notifications
 
-Usage-based billing notifications are available within the [Cloudflare dashboard](https://dash.cloudflare.com) for users looking to monitor their total account usage. 
+Usage-based billing notifications are available within the [Cloudflare dashboard](https://dash.cloudflare.com) for users looking to monitor their total account usage.
 
 Notifications on the following metrics are available:
 - Rows Read

src/content/docs/d1/platform/alpha-migration.mdx

@@ -18,8 +18,8 @@ This guide will instruct you to recreate alpha D1 databases on our production-re
 ## Prerequisites
 
 1. You have the [`wrangler` command-line tool](/workers/wrangler/install-and-update/) installed
-2. You are using `wrangler` version `3.33.0` or later (released March 2024) as earlier versions do not have the [`--remote` flag](/d1/platform/changelog/#change-in-wrangler-d1-execute-default) required as part of this guide
-3. An 'alpha' D1 database. All databases created before July 27th, 2023 ([release notes](/d1/platform/changelog/#new-default-storage-subsystem)) use the alpha storage backend, which is no longer supported and was not recommended for production.
+2. You are using `wrangler` version `3.33.0` or later (released March 2024) as earlier versions do not have the [`--remote` flag](/d1/platform/changelog/#2024-03-12) required as part of this guide
+3. An 'alpha' D1 database. All databases created before July 27th, 2023 ([release notes](/d1/platform/changelog/#2024-03-12)) use the alpha storage backend, which is no longer supported and was not recommended for production.
 
 ## 1. Verify that a database is alpha
 

src/content/docs/d1/reference/migrations.mdx

@@ -12,9 +12,9 @@ Database migrations are a way of versioning your database. Each migration is sto
 
 Currently, the migrations system aims to be simple yet effective. With the current implementation, you can:
 
-* [Create](/workers/wrangler/commands/#migrations-create) an empty migration file.
-* [List](/workers/wrangler/commands/#migrations-list) unapplied migrations.
-* [Apply](/workers/wrangler/commands/#migrations-apply) remaining migrations.
+* [Create](/workers/wrangler/commands/#d1-migrations-create) an empty migration file.
+* [List](/workers/wrangler/commands/#d1-migrations-list) unapplied migrations.
+* [Apply](/workers/wrangler/commands/#d1-migrations-apply) remaining migrations.
 
 Every migration file in the `migrations` folder has a specified version number in the filename. Files are listed in sequential order. Every migration file is an SQL file where you can specify queries to be run.
 

src/content/docs/d1/worker-api/d1-database.mdx

@@ -212,7 +212,7 @@ return Response.json(returnValue);
 
 #### Guidance
 
-- If an error occurs, an exception is thrown with the query and error messages, execution stops and further statements are not executed. Refer to [Errors](/d1/observability/#errors) to learn more.
+- If an error occurs, an exception is thrown with the query and error messages, execution stops and further statements are not executed. Refer to [Errors](/d1/observability/debug-d1/#errors) to learn more.
 - This method can have poorer performance (prepared statements can be reused in some cases) and, more importantly, is less safe.
 - Only use this method for maintenance and one-shot tasks (for example, migration jobs).
 - The input can be one or multiple queries separated by `\n`.

src/content/docs/d1/worker-api/index.mdx

@@ -10,7 +10,7 @@ import { DirectoryListing, Details, Steps } from "~/components";
 You can execute SQL queries on your D1 database from a Worker using the Worker Binding API. To do this, you can perform the following steps:
 
 1. [Bind the D1 Database](/d1/worker-api/d1-database).
-2. [Prepare a statement](/d1/worker-api/d1-database/#dbprepare).
+2. [Prepare a statement](/d1/worker-api/d1-database/#prepare).
 3. [Run the prepared statement](/d1/worker-api/prepared-statements).
 4. Analyze the [return object](/d1/worker-api/return-object) (if necessary).
 
@@ -20,7 +20,7 @@ Refer to the relevant sections for the API documentation.
 
 D1 Worker Bindings API is fully-typed via the [`@cloudflare/workers-types`](/workers/languages/typescript/#typescript) package, and also supports [generic types](https://www.typescriptlang.org/docs/handbook/2/generics.html#generic-types) as part of its TypeScript API. A generic type allows you to provide an optional `type parameter` so that a function understands the type of the data it is handling.
 
-When using the query statement methods [`D1PreparedStatement::run`](/d1/worker-api/prepared-statements/#run), [`D1PreparedStatement::raw`](/d1/worker-api/prepared-statements/#raw) and [`D1PreparedStatement::first`](/d1/worker-api/prepared-statements/#first), you can provide a type representing each database row. D1's API will [return the result object](#return-object) with the correct type.
+When using the query statement methods [`D1PreparedStatement::run`](/d1/worker-api/prepared-statements/#run), [`D1PreparedStatement::raw`](/d1/worker-api/prepared-statements/#raw) and [`D1PreparedStatement::first`](/d1/worker-api/prepared-statements/#first), you can provide a type representing each database row. D1's API will [return the result object](/d1/worker-api/return-object/#d1result) with the correct type.
 
 For example, providing an `OrderRow` type as a type parameter to [`D1PreparedStatement::run`](/d1/worker-api/prepared-statements/#run) will return a typed `Array<OrderRow>` object instead of the default `Record<string, unknown>` type:
 

src/content/docs/d1/worker-api/prepared-statements.mdx

@@ -7,7 +7,7 @@ sidebar:
 
 import { Type, MetaInfo, Details } from "~/components";
 
-This chapter documents the various ways you can run and retrieve the results of a query after you have [prepared your statement](/d1/worker-api/d1-database/#dbprepare).
+This chapter documents the various ways you can run and retrieve the results of a query after you have [prepared your statement](/d1/worker-api/d1-database/#prepare).
 
 ## Methods
 

src/content/partials/workers/wrangler-commands/d1.mdx

@@ -78,9 +78,9 @@ You must provide either `--command` or `--file` for this command to run successf
 - `-y, --yes` <Type text="boolean" /> <MetaInfo text="optional" />
   - Answer `yes` to any prompts.
 - `--local` <Type text="boolean" /> <MetaInfo text="(default: true) optional" />
-  - Execute commands/files against a local database for use with [wrangler dev](#dev).
+  - Execute commands/files against a local database for use with [wrangler dev](/workers/wrangler/commands/#dev).
 - `--remote` <Type text="boolean" /> <MetaInfo text="(default: false) optional" />
-  - Execute commands/files against a remote D1 database for use with [wrangler dev --remote](#dev).
+  - Execute commands/files against a remote D1 database for use with [wrangler dev --remote](/workers/wrangler/commands/#dev).
 - `--persist-to` <Type text="string" /> <MetaInfo text="optional" />
   - Specify directory to use for local persistence (for use in combination with `--local`).
 - `--json` <Type text="boolean" /> <MetaInfo text="optional" />
@@ -101,9 +101,9 @@ wrangler d1 export <DATABASE_NAME> [OPTIONS]
 - `DATABASE_NAME` <Type text="string" /> <MetaInfo text="required" />
   - The name of the D1 database to export.
 - `--local` <Type text="boolean" /> <MetaInfo text="(default: true) optional" />
-  - Export from a local database for use with [wrangler dev](#dev).
+  - Export from a local database for use with [wrangler dev](/workers/wrangler/commands/#dev).
 - `--remote` <Type text="boolean" /> <MetaInfo text="(default: false) optional" />
-  - Export from a remote D1 database for use with [wrangler dev --remote](#dev).
+  - Export from a remote D1 database for use with [wrangler dev --remote](/workers/wrangler/commands/#dev).
 - `--output` <Type text="string" /> <MetaInfo text="required" />
   - Path to the SQL file for your export.
 - `--table` <Type text="string" /> <MetaInfo text="optional" />