What is a technical SEO checklist for a WordPress site?
Technical SEO is everything that affects how search engines access and process your site, as opposed to the words on the page (content) or the links pointing at it (off-page). The job is to remove friction across four stages Google moves through in order: crawl the URL, render the page, index it, and only then consider it for ranking. If a page fails at crawl or index, nothing downstream matters.
On WordPress the surface area is larger than most owners realise. The core CMS, your theme, and every plugin can each add URLs, scripts, and settings that either help or sabotage those four stages. That is why a checklist beats guesswork — you verify each layer instead of assuming the defaults are correct.
Work through the list top to bottom. Foundations first (can Google reach and index the page?), then experience (is it fast and mobile-friendly?), then clarity (canonicals and schema), then hygiene (broken links). Below is the full checklist this article covers.
- Crawlability and robots.txt — can bots reach your pages, and are you accidentally blocking them?
- XML sitemap — is there one clean sitemap submitted to Google Search Console?
- Indexing — are the right pages indexed, and the thin ones kept out?
- Site speed and Core Web Vitals — do real users get LCP, INP, and CLS in the green?
- Mobile-friendliness — does the mobile version (the one Google indexes) work properly?
- HTTPS — is the whole site on a valid SSL certificate with no mixed content?
- Canonicalization — does each piece of content have one canonical URL?
- Structured data — is JSON-LD schema present and valid for your page types?
- Broken links — are internal 404s and redirect chains cleaned up?
How do you make sure Google can crawl your WordPress site?
Crawlability is whether search engine bots can fetch your URLs and the resources (CSS, JavaScript, images) needed to render them. It is controlled mainly by your robots.txt file at yourdomain.com/robots.txt and by robots meta tags on individual pages. Get this wrong and Google never even sees the content.
The single most common WordPress mistake I find is Settings → Reading → 'Discourage search engines from indexing this site' left ticked after launch. That checkbox adds a site-wide noindex and is the number-one reason a fresh WordPress site gets zero organic traffic — check it first, every time.
Understand the difference between the two controls, because they are not interchangeable. robots.txt Disallow tells bots not to crawl a URL; a robots noindex meta tag lets them crawl but tells them not to index. If you Disallow a page in robots.txt, Google can't read its noindex tag — so never block a page you're trying to keep out of the index; use noindex instead.
- Open yourdomain.com/robots.txt and confirm it does not Disallow /wp-content/ or your theme's CSS/JS — Google must render the page to rank it.
- Uncheck Settings → Reading → 'Discourage search engines from indexing this site' on any live site.
- To keep a page out of Google, use a noindex robots meta tag (Yoast/Rank Math set this per page or per template) — not a robots.txt block.
- In Search Console → Settings → Crawl stats, watch for spikes in server errors (5xx) or a rising average response time, which throttle crawling.
- Use Search Console → URL Inspection → 'Test live URL' → 'View crawled page' to confirm Googlebot sees the full rendered HTML, not a blank shell.
How do you set up an XML sitemap and get WordPress pages indexed?
An XML sitemap is a machine-readable list of your indexable URLs that helps Google discover pages faster, especially on large or poorly linked sites. Since version 5.5, WordPress ships a core sitemap at /wp-sitemap.xml automatically. If you run Yoast or Rank Math, they generate a better one at /sitemap_index.xml and disable the core version — that's fine, just make sure only one is active and it's the one you submit.
Each sitemap file is capped at 50,000 URLs and 50MB uncompressed; SEO plugins split large sites into a sitemap index automatically. Submit the index URL once at Search Console → Sitemaps and Google re-reads it on its own schedule.
Indexing is separate from having a sitemap — a sitemap is an invitation, not a guarantee. Use Search Console → Pages (Indexing) report to see what's indexed versus excluded, and read the reason for each exclusion. 'Crawled – currently not indexed' usually means thin or duplicate content; 'Discovered – currently not indexed' means Google is holding off, often a crawl-budget or quality signal.
- Pick one sitemap source (Rank Math or Yoast), and exclude low-value URL types — tag archives, author archives, and media/attachment pages — which otherwise bloat the index with thin pages.
- Submit the sitemap index (e.g. /sitemap_index.xml) at Search Console → Sitemaps and confirm status shows 'Success' with the URL count you expect.
- For a new or important page, use URL Inspection → 'Request Indexing' to nudge a faster crawl — but don't use it as a bulk strategy for hundreds of URLs.
- Review the Pages report weekly; investigate any URL you want ranked that sits under 'Not indexed'.
- Make sure important pages are linked from your menu, footer, or other posts — internal links drive indexing far more reliably than a sitemap alone.
How do you pass Core Web Vitals on a WordPress site?
Core Web Vitals are Google's three real-user speed and stability metrics: Largest Contentful Paint (LCP, main content load), Interaction to Next Paint (INP, responsiveness), and Cumulative Layout Shift (CLS, visual stability). The 'good' thresholds are LCP ≤ 2.5 seconds, INP ≤ 200 milliseconds, and CLS ≤ 0.1, and you need to hit them at the 75th percentile of real visitors — meaning 75% of page loads must be good.
There's a critical distinction: field data (real Chrome users, shown in Search Console → Core Web Vitals and in the CrUX report) is what affects ranking, while lab data (a single test in PageSpeed Insights or Lighthouse) is only a diagnostic. Optimise for the field score, then use the lab test to find what to fix.
WordPress speed is won mostly at the hosting and asset layers. Cheap shared hosting at ₹100–300/month often can't deliver a fast server response (aim for a Time to First Byte under ~600ms); managed WordPress or a small VPS at roughly ₹800–2,000/month usually can. After hosting, caching and images do the heavy lifting.
- Add a caching plugin (WP Rocket, LiteSpeed Cache, or W3 Total Cache) to serve static HTML and cut TTFB.
- Compress and serve images as WebP, and set explicit width and height on every image so it can't cause layout shift (protects CLS).
- Enable lazy-loading for below-the-fold images and defer non-critical JavaScript — heavy third-party scripts are the usual INP killers.
- Put a CDN in front (Cloudflare has a free tier) so assets load from a server near the visitor.
- Audit plugins: each active plugin adds code — deactivate and delete anything you don't need, since 30+ plugins is a common cause of slow WordPress.
- Re-test in PageSpeed Insights after each change, and watch the field data in Search Console → Core Web Vitals over the following 28 days.
Is your WordPress site mobile-friendly and served over HTTPS?
Google uses mobile-first indexing, which means it crawls and ranks the mobile version of your site — not the desktop one. If your mobile layout hides content, breaks tap targets, or forces horizontal scrolling, that's the version being judged. Almost every modern WordPress theme is responsive, but plugins, custom code, and large images still break mobile in practice, so test on a real phone, not just the desktop preview.
HTTPS has been a confirmed ranking signal since 2014 and is now the baseline — browsers flag plain HTTP sites as 'Not secure', which kills trust and conversions. WordPress and every reputable Indian host support free SSL via Let's Encrypt, so there's no cost reason to skip it.
The common failure isn't the certificate itself but a half-finished migration: the site loads on HTTPS but still pulls some images or scripts over HTTP ('mixed content'), or HTTP URLs don't redirect. Both leave you with an insecure padlock and duplicate HTTP/HTTPS URLs.
- Confirm a responsive theme, a proper viewport meta tag, tap targets around 48px, body text ≥ 16px, and no horizontal scroll on a real phone.
- Run Lighthouse (Chrome DevTools) in mobile mode and check the mobile Core Web Vitals separately — they're usually worse than desktop.
- Verify a valid SSL certificate installed and not expired (hosts auto-renew Let's Encrypt every 90 days).
- Set WordPress Address and Site Address to the https:// version in Settings → General.
- Force a single 301 redirect from http:// to https:// (most hosts and caching plugins have a one-click 'Force HTTPS' option).
- Fix mixed content — update internal image/script URLs to https (a plugin like Really Simple SSL handles this) so the padlock is clean site-wide.
How do you handle canonicalization and duplicate content in WordPress?
A canonical tag (rel="canonical") tells Google which URL is the master version of a page when several URLs show similar content. WordPress is a duplicate-content factory by default — the same post can be reachable via the post URL, comment-reply parameters (?replytocom=), feed URLs, pagination, and category or tag archives — so canonicals matter more here than on most platforms.
Yoast and Rank Math automatically add a self-referencing canonical to every page, which solves most of this. Your job is to confirm it's happening and to handle the site-level duplicates the plugin can't decide for you: the www vs non-www version, http vs https, and trailing-slash consistency.
Pick one canonical version of your domain and 301-redirect the rest. Serving both https://www.site.com/page and https://site.com/page/ as live, indexable URLs splits your ranking signals across duplicates for no reason.
- View any page's source (Ctrl+U) and confirm exactly one rel="canonical" tag pointing to the clean, preferred URL.
- Choose www or non-www, set it consistently in Settings → General, and 301-redirect the other version.
- Keep trailing slashes consistent with your permalink structure so /page and /page/ don't both resolve as separate live URLs.
- Set thin archives (tag pages, author pages, date archives) to noindex in your SEO plugin rather than letting them compete with your real pages.
- For paginated archives, let each page self-canonicalize (page 2 canonicalizes to page 2), and avoid pointing every page back to page 1 — that hides deeper content from Google.
How do you add structured data and fix broken links in WordPress?
Structured data is code (use JSON-LD, Google's preferred format) that labels what a page is — an article, a product, a local business, an FAQ — so Google can understand it and potentially show rich results like star ratings or FAQ dropdowns. Rank Math and Yoast add core schema automatically: Article, Organization, WebSite, and BreadcrumbList. Beyond that, add the types your business needs — LocalBusiness with accurate NAP (name, address, phone) for an Indian SMB with a physical location, Product with price and availability for e-commerce, and FAQPage for pages with genuine Q&A.
Never mark up content that isn't visible on the page, and always validate — Google penalises spammy or mismatched schema. Test every template with Google's Rich Results Test and the Schema.org Validator before assuming it works.
Broken links are internal or outbound links that return a 404. They waste crawl budget, leak the ranking value of any inbound links pointing at the dead URL, and frustrate users. On WordPress they pile up quietly when you delete posts, change slugs, or move products.
- Add LocalBusiness (with NAP), Product, or FAQ schema where relevant, and keep it in sync with the visible content.
- Validate each page type in Google's Rich Results Test; fix every error before publishing schema site-wide.
- Crawl the site with Screaming Frog (free up to 500 URLs) to list all 4xx internal links, or check Search Console → Pages → 'Not found (404)'.
- Fix broken links by updating the link to the correct URL, or 301-redirecting the old URL to the closest live page when the URL changed.
- Avoid redirect chains (A → B → C); point old URLs straight to the final destination, and don't 301 dead pages to the homepage en masse — redirect to a relevant page or serve a proper 404.