The short answer
Inspect the HTML returned for an article as well as the hydrated browser page. The title, main answer and navigation should be available in a stable, understandable form. A route that looks correct only after a client-side request needs a separate discovery and failure-state review.
A worked example
A fictional journal shows cards after JavaScript loads, but an article endpoint returns an empty main element when its database request fails. The team tests both the successful server response and the unavailable state. It avoids replacing missing content with a generic success page that would obscure the failure.
A practical checklist
- Fetch a representative article response and inspect the main heading, body and links. Compare that output with what a browser user sees after hydration.
- Test missing and unpublished slugs. They should not expose drafts or silently render an unrelated article under the requested URL.
- Check metadata, canonical information and structured data against the same content record. Confirm behavior after an editor updates or archives the record.
What to avoid
Avoid assuming server rendering alone makes a page discoverable or performant. Crawler access, indexing directives and content quality still need review. Keep implementation claims specific: say that tested content appears in returned HTML rather than claiming guaranteed search visibility.
A useful follow-up
Does server rendering guarantee indexing?
No. It can make content available in the response, but discovery, access and indexing decisions remain separate.
