JavaScript SEO: make article text and links available in the initial HTML

Serve the article before interactive scripts run

A reader should receive the headline, article text and ordinary links when the page first loads. JavaScript, the code that adds interactive behavior in the browser, can enhance search or saving without being the only way to obtain the article.

Google processes JavaScript pages through crawling, rendering and indexing. Crawling retrieves the page; rendering executes code to assemble its visible content. Serving essential article content in the initial HTML, the document sent by the server, reduces your dependence on that extra rendering step. (Google JavaScript SEO basics ↗)

Decide what a broken script may take away

An article has two layers: the reporting and conveniences around it. If a search script fails, losing interactive filtering is tolerable. Losing the article, source links or route to another story is not.

Use one article as the migration test

A page that paints the masthead quickly but waits for JavaScript to fetch its body has not passed the reading test. This is why a speed score and a screenshot of a fully loaded page are insufficient evidence for this particular requirement.

Use View Page Source and find a distinctive sentence from the conclusion. Check its context: a sentence inside a data script is not yet readable article HTML. Then disable JavaScript for the page, reload and read to the conclusion. Follow a source and another article through ordinary links. These are reader-resilience checks; Google can render JavaScript, so this is not a claim that every script-dependent page is unindexable.

Open an invented article address and have the developer inspect its HTTP response status. It should be 404 for a missing page. A screen that says “not found” while the server returns 200 gives people and crawlers conflicting information.

Test a cold visit before a migration

Open the article in a clean browser with scripts disabled, then request its initial response and look for its title, main text and ordinary links. Compare those with the full interactive page. A visitor should be able to start reading and follow a source even if a search widget fails. Record anything useful that appears only after the script loads so you know which reader tasks depend on it.

Check at least one old story, one newly published story, and a page that legitimately does not exist. If the migration returns a visually empty shell for an old article or sends a successful status for a missing one, flag the route and exact response for a developer. Test again from a fresh session after the repair. A screenshot of your own browser after it has already loaded the application can miss the original failure.

Set an acceptance boundary for essential content

For a premium article with a public introduction, test what an unauthenticated request receives before JavaScript runs. It should show the portion readers are meant to see and give them a path to subscribe. Test the authorized experience separately. A migration that exposes the complete premium story while hiding it visually has a different failure from one that withholds even the public explanation.

Create a small release checklist with the exact article, the expected public text, the expected authorized text, and a link a reader should be able to follow. Repeat the test after the deployed page has been cached. The same checklist can catch both missing content and accidental exposure.