NEAPTIDE · LAB-STREAMING · October 12, 2026

Question: Where do title, description and canonical occur in the HTTP HTML and rendered DOM for three Next.js metadata modes?

Scope: Next.js 15.5.22; React and React DOM 19.2.6; Node v25.2.1. Local production builds on macOS. Two configurations from identical application source: default and htmlLimitedBots: /.*/. Both routes use force-dynamic; “static” refers to a metadata object, not static route generation. The async function has a deliberate 250 ms delay and no external fetch.

Nine conditions: static metadata/default, async metadata/default, async metadata/blocking, each requested with browser-like Chrome 134, Googlebot/2.1 and Twitterbot/1.0 User-Agent strings. Exact strings and common request headers are in protocol.json and results.json. Each condition ran twice: 18 completed HTTP 200 responses. All three expected tag values appeared once per response, and placement agreed across both rounds.

The collector stores complete response bytes and SHA256, HTTP headers and read-chunk timestamps. An HTML parser counts actual elements; strings in React scripts are not additional title/meta/link tags. Placement is the head or body region in the emitted response. Local chunk timings are diagnostic observations, not latency or Core Web Vitals benchmarks.

Three independent browser page loads covered the three modes. The connected browser sent a Chrome 154 User-Agent, different from the collector's Chrome 134-like string. DOM captures record the actual received header, tag values and ancestry. They do not simulate a bot renderer. Browser screenshots show the fixture and configuration; metadata positions are evidenced by DOM JSON rather than the screenshot alone.

Observed placement (title, description and canonical agreed in each cell):
                         Browser-like   Googlebot-UA   Twitterbot-UA
Static / default         head           head           head
Async / default          body           body           head
Async / blocking         head           head           head

Real browser DOM: static/default head; async/default body; async/blocking head.

Interpretation: body placement can be a consequence of the tested streaming configuration. It does not prove metadata loss or search-engine acceptance. Next.js documents streaming body metadata for capable bots, while Google explicitly requires an HTML canonical link in head. Our local experiment does not resolve how Google's actual systems would treat the tested body canonical. Check the tag-specific requirement and the real deployed URL; do not infer Google-selected canonical, indexing or rankings from this fixture.

Limitations: one Next.js version and one browser build; artificially delayed local requests; no CDN, production load, remote crawler, cache components, client-side navigation, errors or metadata failure paths; no indexing, ranking, citation, traffic, conversion or Core Web Vitals measurement. Both rounds and DOM inspection were performed by the same researcher. The fixture uses reserved example.test URLs and noindex/nofollow and must not be deployed as a production template.

Files: results.json contains the protocol, analysis, source register and complete HTTP/DOM observations. evidence.zip includes exact HTML responses, per-response records, DOM snapshots/screenshots and freeze manifests. reproduction.zip includes the fixture, dependency lockfile, collector and original protocol; see README.txt for commands. No credentials, private account data or production cookies were used.

Reproduction check: a freshly extracted archive was installed with npm ci --ignore-scripts and both production builds completed. All 18 repeated HTTP responses matched the original count, value and head/body placement fields. Build IDs, chunk boundaries and timings were not compared.