On this page
Start with the indexability chain
A page has to be reachable, return the right status code, allow crawling where appropriate, render properly and be judged worth indexing. Check each link in that chain instead of assuming a sitemap submission guarantees inclusion. When crawl behaviour is unclear, look at server logs and compare the rendered HTML with what the page should contain.
| Stage | What to check | Where to look |
|---|---|---|
| Reachable | Internal links, sitemap entries, no orphan pages | Crawler, XML sitemap |
| Correct status | 200 for live pages, single-hop 301s, real 404s | Crawler, server logs |
| Crawlable | robots.txt rules, blocked resources | robots.txt report, Search Console |
| Renderable | Key content present in rendered HTML | URL Inspection, rendered source |
| Indexable | No stray noindex, canonical points to itself | Page source, URL Inspection |
Canonicalisation and duplication
Choose one preferred URL for each unique resource. Keep internal links, redirects and canonical tags in agreement with each other. Avoid generating dozens of near-identical location pages, and merge thin duplicates into stronger pages that meet distinct needs.
Performance and accessibility
Measure Core Web Vitals with real-user data where it exists, and test templates rather than only the homepage. Serve properly sized, compressed images, limit render-blocking resources, keep text readable, write alt text for meaningful images and make sure everything works with a keyboard. Fast pages matter because they work better for people.
Structured data and validation
Use Person on the official biography, Book on individual book pages, Article on editorial pages and BreadcrumbList where a visible breadcrumb exists. Every property should match what visitors can verify on the page. Validate the syntax and read the eligibility rules, because schema does not guarantee rich results.
Quality assurance after release
- Status codes and redirects
- Canonical targets
- Mobile rendering
- XML sitemap contents
- noindex rules
- Internal links
- Search Console coverage and enhancement reports
Keep a dated change log so that an unexpected traffic shift can be traced to a cause instead of guessed at.
Frequently asked questions
Can JavaScript pages rank?
Yes, but extra rendering complexity can cause delays and failures. Server-rendered core content is usually easier to maintain.
Is a perfect performance score required?
No. Focus on real user experience and field data rather than a single lab score.
Should every page be indexed?
No. Index pages that offer distinct public value, and keep internal search results, duplicates and other low-value URLs out.

