Add in code examples for metadata

Author: kodster28

src/content/docs/style-guide/how-we-docs/metadata.mdx

@@ -5,6 +5,8 @@ meta:
   title: Metadata | How we docs
 ---
 
+import { GitHubCode } from "~/components";
+
 Page-level metadata - content type, associated products, last updated, word count - lets you take a broader, more strategic view of your content.
 
 It helps you answer questions like the following:
@@ -47,13 +49,30 @@ We set these values at two different levels, the folder level and the page level
 
 We set two values at a folder level, `Product` and `Product Group`. We take this approach because we can assume that these values apply every page within that folder.
 
-{/* GitHubCode example of a product.yaml file */}
+For example, here's the content from our [DNS folder](https://github.com/cloudflare/cloudflare-docs/blob/production/src/content/products/dns.yaml).
+
+<GitHubCode
+	repo="cloudflare/cloudflare-docs"
+	file="src/content/products/dns.yaml"
+	commit="eeb4aadac6e1ca1f25f698385c1217cabda1adac"
+	lang="yaml"
+	code={{ title: "dns.yaml", mark: [4, 6] }}
+/>
 
 ### Page-level attributes
 
 We primarily set page-level attributes through the [page's frontmatter](/style-guide/frontmatter/custom-properties/).
 
-{/* GitHubCode example of a specific file with a lot of them */}
+For example, here are the values set for our [Build a Slackbot tutorial](/workers/tutorials/build-a-slackbot/).
+
+<GitHubCode
+	repo="cloudflare/cloudflare-docs"
+	file="src/content/docs/workers/tutorials/build-a-slackbot/index.mdx"
+	commit="c33f3a8f71fd7b8c7d68d9f0b179abdc1e8d330a"
+	lang="mdx"
+	lines="1-10"
+	code={{ title: "build-a-slackbot.mdx", mark: [2, 4, 6, 7] }}
+/>
 
 However, the `last_modified` value is pulled automatically from the git history of a file.
 
@@ -73,9 +92,16 @@ For example, these are the `meta` properties and values on the [AI Audit - Get S
 <meta name="pcx_last_modified" content="7" >
 ```
 
-We render these values using a custom override for our [`Head.astro`]() file.
+We render these values using a custom override for our [`Head.astro`](https://github.com/cloudflare/cloudflare-docs/blob/production/src/components/overrides/Head.astro) file. If specific values are set, we then add them as meta tags onto the page.
 
-{/* GitHubCode for Head.astro */}
+<GitHubCode
+	repo="cloudflare/cloudflare-docs"
+	file="src/components/overrides/Head.astro"
+	commit="80573b88bd2a491240e404938feb506d347093db"
+	lang="ts"
+	lines="65-72"
+	code={{ title: "Head.astro" }}
+/>
 
 ### Benefits
 
@@ -91,14 +117,6 @@ Additionally, this decisions means that our GitHub repo is always the source of
 
 It's difficult to avoid errors with this kind of metadata, specifically because we are relying on freeform text entry in the frontmatter of individual files.
 
-We utilize `zod` schemas heavily in our Astro site, which are defined at [tbd](/tbd/).
+We utilize [Zod schemas](https://zod.dev/) heavily in our Astro site, which are defined in [`src/schemas/`](https://github.com/cloudflare/cloudflare-docs/tree/production/src/schemas).
 
 These allow us to provide Intellisense guidance for contributors using IDEs for local development.
-
-### Optional or required
-
-At the moment, most of our Zod schemas are purely optional, meaning that they will not cause a build to fail.
-
-However, we do have one value, `tags`, that we enforce an allowlist as part of our schema validation. We enforce this schema specifically because we render it as a customer-facing facet for our [search page](/search/), meaning that typos are more disruptive than for other types of metadata.
-
-To try and make this list a bit more flexible, we've included `alternate` values that can lead to the same presented value.