docs: the Google Tag Manager container 404s and its loader never renders; four dead outbound links

The documentation site's Google Tag Manager container has been returning 404 since July 2025, and half of the snippet that loads it is never rendered at all. Separately, four outbound prose links in docs/ are dead. Verified on main (c3f1999d), plus the deployed site at https://docs.pr-agent.ai/.

This deliberately excludes the codium.ai image hosts — those are #3174 / #3257 and I am not re-reporting them here.

1. The analytics container 404s, and the loader is dead code

docs/overrides/partials/integrations/analytics/custom.html:6 and docs/overrides/main.html:11 both name container GTM-5C9KZBM3. Neither endpoint exists:

$ curl -s -o /dev/null -w "%{http_code}\n" "https://www.googletagmanager.com/gtm.js?id=GTM-5C9KZBM3"
404
$ curl -s -o /dev/null -w "%{http_code}\n" "https://www.googletagmanager.com/ns.html?id=GTM-5C9KZBM3"
404

For comparison, the container currently on qodo.ai answers:

$ curl -s -o /dev/null -w "%{http_code} %{size_download}\n" "https://www.googletagmanager.com/gtm.js?id=GTM-M6PJSFV"
200 567254

How it got here: 4df097c2 (2024-11-25) changed the ID from GTM-5C9KZBM3 to GTM-M6PJSFV, and c4dd07b3 ("squashing revert commits", 2025-07-13) put GTM-5C9KZBM3 back. main.html was never part of either change and has carried GTM-5C9KZBM3 since it was added.

Worse, only one of the two halves ever reaches a page. mkdocs-material includes partials/integrations/analytics/<provider>.html only when extra.analytics.provider is set, and docs/mkdocs.yml has no extra.analytics block at all. So custom.html is never rendered:

$ mkdocs build -f docs/mkdocs.yml -d /tmp/site      # mkdocs 1.6.1, mkdocs-material
$ grep -rc "gtm.js" /tmp/site/index.html
0
$ grep -c "ns.html" /tmp/site/index.html
1
$ grep -rl "GTM-5C9KZBM3" /tmp/site/ | wc -l
43

The deployed site matches exactly — gtm.js appears zero times, the <noscript> iframe appears once:

$ curl -s -L https://docs.pr-agent.ai/ | grep -c "gtm.js"
0
$ curl -s -L https://docs.pr-agent.ai/ | grep -c "ns.html?id=GTM-5C9KZBM3"
1

So the current state is: no analytics are collected on any page, and every one of the 43 built pages ships a hidden iframe to a 404. That is not a measurement gap that a corrected ID would close — it is a decision, and it is the maintainers':

• (a) Remove it. Delete custom.html and the {% block scripts %} override in main.html. Nothing is lost, because nothing is being collected today.
• (b) Wire it up properly with a container this project controls: add extra.analytics.provider: custom to mkdocs.yml, put the real ID in both files. This starts collecting where nothing is collected now, so it is a privacy-visible change and probably wants a consent notice.

I would take (a) unless someone holds a container for this fork. It is also the only option that does not require a secret nobody has published.

2. Four dead outbound links in prose

The first has an unambiguous replacement: https://docs.ollama.com/context-length answers 200 and documents OLLAMA_CONTEXT_LENGTH.

The second is an example of the global-configuration mechanism, and the same paragraph still says "the GitHub organization qodo-ai", which this fork is not. The mechanism itself is correctly documented above it; only the worked example is stale. It needs a decision — point it at a repository that exists, or drop the example and keep the mechanism.

The third may be intentional. The URL is the A2A extension identifier that the agent card advertises, and an extension URI is not required to resolve. If that is the case it is worth a word in the docs, since it reads as a link.

3. What is not broken, so nobody re-checks it

I checked all 213 resolvable absolute URLs under docs/. Everything else that came back non-200 was a false positive and needs no action: placeholder hosts (jira.example.com, https://YOUR-QDRANT-URL, https://dev.azure.com/YOUR_ORGANIZATION/), API base URLs that are not browsable (https://api.openai.com/v1, https://api.moonshot.cn/v1, https://bedrock-runtime.us-east-1.amazonaws.com), and hosts that 403 a scripted GET but serve a browser (platform.openai.com/api-keys, developers.asana.com, medium.com).

Suggested scope

1. Settle (a) or (b) on the analytics block — one PR either way.
2. Fix the ollama link — mechanical, one line.
3. Decide the pr-agent-settings example — one line, but it is a naming decision.
4. Confirm whether the MOSAICO extension URI is deliberately non-resolving.

Happy to take 1 (as (a)), 2 and 3 in one docs PR once the direction on 1 and 3 is settled. Item 4 is a question rather than a change.