You launched the site three months ago. It looks good, the content is decent, and yet Google Search Console shows 40 impressions a week and the pages you care about are not indexed at all. Before you write another blog post or buy another backlink, the problem is almost always further down the stack — in the crawlability, speed and markup layer that nobody looked at because the site "looked fine".
This is a working technical SEO checklist for a new website. It is not a list of 87 items you will never finish. It is the sequence we actually run, in the order that matters, with honest notes on which items move rankings and which ones are just tidy.
Start by confirming Google can actually see the site
Every technical SEO checklist should begin here, because if crawling is broken nothing else you do registers. Most new-site disasters we get called in to fix are one of four things, and three of them take under ten minutes to check.
The staging robots.txt that shipped to production
A developer blocks crawlers on the staging server with Disallow: / so the half-finished site does not get indexed. Then the site goes live and nobody removes it. Open yourdomain.com/robots.txt right now. If you see a bare Disallow: / under User-agent: *, that is your entire problem and it has been for however long the site has been live.
The noindex meta tag left in the template
Same story, different mechanism. WordPress has a setting under Settings, then Reading called "Discourage search engines from indexing this site". It writes a noindex directive into every page. View the page source and search for the word "noindex". If it is there, that page will never rank, no matter how good it is.
The site is behind a login or a JavaScript wall
Single-page applications that render everything client-side can be crawled by Google, but rendering is a second queue and it is slower and less reliable than plain HTML. If your product pages only appear after a JavaScript fetch, use the URL Inspection tool in Google Search Console, run "Test live URL", and look at the rendered HTML. If your body text is not in there, Google is not seeing it either.
No sitemap and no internal links to deep pages
Google finds pages by following links. A page with no internal links pointing to it and no sitemap entry is effectively invisible. This is common on e-commerce sites where category pagination is done in JavaScript and page 4 onwards is unreachable.
Set up Google Search Console properly on day one
Search Console is free, it is the only source of truth about how Google sees your site, and a surprising number of businesses paying a monthly SEO retainer have never been given access to it. Ask for it. If your agency will not give you Search Console access to your own domain, that tells you something.
Verify at the domain level, not the URL prefix level
Domain-level verification uses a DNS TXT record and covers http, https, www, non-www and every subdomain in one property. URL-prefix verification covers only one exact variant, which means you will spend months looking at data from https://www.yoursite.com while half your traffic lands on https://yoursite.com and shows up nowhere.
Submit the XML sitemap and then actually read the report
Submitting the sitemap is not the point. The point is the Pages report underneath it, which tells you exactly why URLs are excluded: "Crawled – currently not indexed", "Discovered – currently not indexed", "Duplicate without user-selected canonical", "Excluded by noindex tag". Each of those has a different fix, and the report is telling you which one you have.
Understand what the two "not indexed" states mean
Discovered – currently not indexed means Google knows the URL exists but has not spent crawl budget on it. On a small site this usually means the page looks low-value based on internal linking. Crawled – currently not indexed is harsher: Google fetched the page, read it, and decided not to include it. That is a content quality signal, not a technical one, and no amount of sitemap resubmission will change it.
Get the URL and canonical structure right before you have traffic
Changing URLs later costs you rankings and requires a redirect map that somebody has to maintain. Getting this right in week one is nearly free. Getting it right in month eighteen is a project.
Pick one hostname and redirect everything else to it
A site can be reachable at four addresses: with and without www, over http and https. Pick one as canonical — https and either www or non-www, it genuinely does not matter which — and 301 redirect the other three to it. Test all four in a browser and confirm each lands on the same final URL with a single redirect hop, not a chain.
Self-referencing canonical tags on every page
Every indexable page should carry a canonical tag pointing at its own clean URL. This protects you when someone links to your page with tracking parameters appended, or when your CMS generates the same content at two paths. The failure mode we see most often is a site-wide canonical hardcoded to the homepage, which tells Google every page on the site is a duplicate of the homepage. That will remove your entire site from search results.
Decide on trailing slashes and stick to it
/about and /about/ are different URLs. Your server should redirect one to the other consistently. Pick whichever your framework does naturally and make sure internal links match, so you are not passing every click through a redirect.
Core Web Vitals: what to fix and what to ignore
Core Web Vitals are three real, measurable metrics that Google collects from actual Chrome users. They are a genuine ranking input, but a modest one — a fast page with weak content will not outrank a slow page with the answer. Fix them because slow sites lose conversions, and treat the ranking effect as a bonus.
| Metric | What it measures | Good | Most common cause of failure |
|---|---|---|---|
| LCP | Time until the largest visible element renders | Under 2.5s | Huge unoptimised hero image; slow server response |
| INP | Delay between a user interaction and visible response | Under 200ms | Heavy JavaScript blocking the main thread |
| CLS | How much the layout jumps while loading | Under 0.1 | Images and ads without width and height set |
LCP is usually one image and one server setting
On most business websites the largest contentful paint element is the hero image or the H1 text block. If it is an image, the fixes are boring and effective: serve it in WebP, size it to the actual display dimensions instead of uploading a 4000px camera file, and remove any lazy-loading attribute from that one image because lazy-loading the thing above the fold delays it by definition. If your server takes 800ms to return HTML, no front-end optimisation will save you — that is a hosting or a database query problem.
INP is a JavaScript diet, not a plugin
Interaction to Next Paint replaced First Input Delay because FID only measured the first interaction and was too easy to pass. INP measures responsiveness throughout the visit. If you are on WordPress with a page builder, four analytics scripts, a chat widget and a popup plugin, your INP is bad because there is simply too much script competing for the main thread. The fix is deleting things, which is unglamorous and is why it rarely gets done.
CLS is the cheapest win on this list
Set explicit width and height attributes on every image and video so the browser reserves the space before the file arrives. Reserve fixed height for ad slots and embeds. Load custom fonts with font-display: swap and a matched fallback so text does not reflow when the webfont lands. An afternoon of work usually takes CLS from failing to passing.
Field data beats lab data
PageSpeed Insights shows two sections. The top one is field data from real Chrome users over the last 28 days — that is what Google uses. The bottom is a Lighthouse lab simulation on a throttled connection. Chasing a Lighthouse score of 100 while your field data still fails is wasted effort. A new site has no field data yet, so use the lab score as a proxy and check back after a month of real traffic.
Mobile-first is not a slogan in the Indian market
Google indexes the mobile version of your site. Not the desktop version with a mobile fallback — the mobile version is the version. And in India the practical reality is that a large share of your visitors are on mid-range Android phones on 4G in a building with two bars of signal.
Test on a real cheap phone, not a desktop browser resize
Chrome DevTools device mode shows you the layout. It does not show you what a 2GB-RAM phone does with 3MB of JavaScript. Borrow an entry-level Android handset, load your site over mobile data, and time how long until you can tap something. That number is your real user experience.
Content parity between mobile and desktop
If your mobile template hides sections, collapses content into accordions, or drops the sidebar with all your internal links, Google indexes the reduced version. Accordions are fine as long as the content is in the HTML. Content that is only fetched when the user taps is a different matter.
Tap targets, font size and the sticky WhatsApp button
Buttons under roughly 48 pixels tall are hard to hit accurately. Body text under 16px forces zooming. And the floating WhatsApp button that half of Indian business sites carry — useful for conversion, genuinely — frequently covers the "Add to cart" button on small screens. Check it on a 360px-wide viewport.
Structured data that is worth adding
Schema.org markup does not directly raise rankings. It makes your result eligible for rich features — star ratings, FAQ dropdowns, breadcrumbs, product price and stock status — which raise click-through rate on the position you already hold. That is a real and worthwhile effect, and it is also the reason people over-invest in it.
- Organization on the homepage: legal name, logo, official social profiles, contact point. Cheap, do it.
- LocalBusiness if you have a physical address customers visit: address, phone, opening hours, geo coordinates.
- Product on e-commerce pages: price, currency, availability, SKU, aggregate rating if you have genuine reviews.
- BreadcrumbList on any site more than two levels deep — it changes the URL line in search results into a readable path.
- Article on blog posts: headline, author, published and modified dates.
- FAQPage only where a genuine FAQ exists on the visible page. Google has narrowed which sites get FAQ rich results, so treat it as optional now rather than a guaranteed win.
Use JSON-LD and validate it
JSON-LD in a script tag is Google's preferred format and it is the easiest to maintain because it sits separately from your visible markup. Validate with the Rich Results Test for eligibility and the Schema Markup Validator for correctness. The most common error is marking up prices or ratings that do not appear anywhere on the visible page, which is a policy violation and can get your rich results removed.
Indexing hygiene as the site grows
A ten-page brochure site has no indexing problems. A 4,000-URL e-commerce site with faceted navigation has thousands, and they compound quietly.
Faceted navigation creates near-infinite URLs
Filters for colour, size, price range and brand combine into a very large number of URL permutations, most of which show nearly identical products. Left unchecked, Google crawls these instead of your real category and product pages. The standard approach: allow indexing of one or two high-demand filter combinations that people genuinely search for, canonicalise the rest back to the parent category, and block obviously useless parameter combinations in robots.txt.
Thin and duplicate pages dilute the site
Auto-generated location pages that differ only by city name, tag archives with one post, empty category pages, and the same product description across twelve listings all read as low-value. Noindex them or consolidate them. Fewer strong pages beat many weak ones.
Fix redirect chains and soft 404s
A redirect chain of A to B to C wastes crawl budget and leaks a little signal at each hop. Point A directly at C. A soft 404 — a page that says "product not found" but returns HTTP 200 — confuses Google into indexing empty pages. Return a real 404 or 410 status code.
HTTPS, hosting and the boring infrastructure layer
Valid certificate, no mixed content
HTTPS is a baseline expectation. Free Let's Encrypt certificates are fine for almost every business site — you do not need a paid EV certificate for SEO. What does matter is mixed content: if your HTTPS page loads an image or script over plain http, browsers will flag it and some assets will be blocked entirely.
Server location and response time
If most of your customers are in India, hosting in Mumbai or Chennai will beat hosting in Virginia on time to first byte by a meaningful margin, and TTFB feeds directly into LCP. Shared hosting at ₹200 a month will show up as a slow server response under any load. Moving to a small VPS or decent managed hosting in the ₹1,000–3,000 per month range is usually the single highest-leverage speed fix available, and it costs less than one hour of developer time.
A CDN, if and only if you need one
If your traffic is entirely domestic and your server is in India, a CDN adds caching benefits but the geographic argument is weak. If you serve NRI customers or ship internationally, a CDN is worth the setup. Do not add one because a checklist told you to.
What is on this checklist that you can skip
Being honest about the low-value items saves more time than the high-value ones save you effort.
- Meta keywords tag. Google has ignored it for well over a decade. If a vendor is charging you for it, that is a signal about the vendor.
- Perfect Lighthouse scores. Going from 85 to 100 typically buys you nothing in rankings and costs days.
- Keyword density targets. Not a thing. Write for the reader.
- Automated sitemap pings. Google deprecated the sitemap ping endpoint. Submitting once in Search Console is enough.
- Disavow files unless you have a manual action or a genuine history of buying links. Google is good at ignoring junk links on its own.
- AMP. No longer required for the Top Stories carousel and it adds a whole parallel version of your site to maintain.
A realistic order of operations
If you are handing this to a developer, this is the sequence that gets results fastest for the least effort.
- Check robots.txt and noindex tags. Fix immediately if broken.
- Verify Google Search Console at domain level, submit the XML sitemap.
- Consolidate to one hostname with clean 301s and self-referencing canonicals.
- Fix CLS — image dimensions and font loading. One afternoon.
- Fix LCP — compress the hero image, check server response time, upgrade hosting if TTFB is over 600ms.
- Test on a real budget Android phone and fix what is broken.
- Add Organization, LocalBusiness and Breadcrumb schema.
- Review the Search Console Pages report after two weeks and work the exclusion reasons.
- Only then start on INP and JavaScript reduction, which is the expensive one.
Conclusion: fix the first six items, then write content
Technical SEO has a sharp diminishing return. Steps one through six on that list account for most of the outcome and can usually be completed in two to three days of developer time. Everything after that is refinement.
The recommendation for a new website: run the crawlability and canonical checks yourself this week — they cost nothing and they are where the catastrophic failures hide. Budget a one-time technical audit and fix in the ₹15,000 to ₹40,000 range rather than a monthly retainer, because the technical layer is largely a fixed problem you solve once. Then put your recurring budget into content and genuine local visibility, which is where the compounding actually happens. A technically flawless site with nothing worth reading ranks for nothing.