Technical SEO is the work of making a website accessible to search engines, helping them render its content and identify the pages that belong in search results. It covers crawling, indexing, canonical URLs, site structure, performance, and the technical settings behind those systems.
A page can look fine in your browser while telling Google not to index it. A redesigned site can work perfectly for visitors while its canonical tags still point to a staging domain. These are the kinds of problems a technical SEO audit should find and resolve.
This guide explains what to check, how to investigate a warning, and how to confirm that a fix worked. The examples focus on business websites and WordPress, with additional checks for online stores.
What technical SEO does, and where it stops
Technical SEO removes obstacles between your content and the systems that discover it. It cannot turn an irrelevant page into a useful answer or guarantee that an accessible page will rank.
Four terms help separate the stages:
- Discovery: a search engine learns that a URL exists, often through links or a sitemap.
- Crawling: it requests the URL and downloads the response.
- Rendering: it processes the page, including supported JavaScript, to understand the content produced.
- Indexing: it evaluates the content and decides whether, and under which canonical URL, to include it in its index.
Ranking is a separate question: which indexed results best serve a particular search? Google’s minimum technical requirements establish eligibility, not a promise of indexing or visibility.
For titles, headings, copy, and page-level content improvements, use our on-page SEO checklist. This guide concentrates on access, technical signals, and problems that can affect entire groups of pages.
If the page is indexed but still performs poorly, use our guide to diagnosing Google ranking problems to distinguish relevance, competition, and click changes from technical barriers.
Technical SEO checklist: fix the biggest barriers first
Start with pages that support enquiries, purchases, or important customer questions. Check the homepage and one example of each main template before expanding the audit.
| Priority | Check | What needs attention |
|---|---|---|
| Immediate | Availability | Important pages return errors, time out, or show a security challenge to crawlers. |
| Immediate | Indexing instructions | Pages intended for search have accidental noindex rules or blocked access. |
| High | Canonical URLs | A template points to a staging domain, an unrelated page, or a retired address. |
| High | Rendered content | Essential copy or navigation disappears when the page is rendered for inspection. |
| High | Discovery and redirects | Important pages lack incoming links or old URLs lead to errors or the wrong destination. |
| Next | Mobile performance | Shared templates load slowly, respond poorly, or shift while visitors interact. |
| Next | Structured data | Markup contradicts visible content or contains errors affecting an applicable search feature. |
These priorities depend on impact. A broken checkout needs urgent attention even if it has no indexing problem. A crawler warning about an intentionally excluded account page may require no change.
1. Establish what Google can access and has indexed
Use Google Search Console alongside a website crawler. They answer different questions: a crawl shows what your site currently returns to that tool; Search Console provides information about Google’s processing of your URLs.
- Choose a URL that should appear in search, such as a core service page.
- Open URL Inspection and review its reported indexing status, last crawl, and canonical information where available.
- Run the live test to check current access. Compare it with the stored result, which may describe an earlier version.
- Inspect the available HTML and screenshot for the main content and navigation.
- Check another page using the same template to see whether the problem is shared.
A successful live test does not establish that a page is already indexed or that Google will select it as canonical. Google explains these distinctions in its URL Inspection documentation.
A crawler such as Screaming Frog can collect response codes, canonical tags, and indexing directives across your site. Use our SEO tools comparison if you need help choosing the software; the audit here is about interpreting and fixing the findings.
Keep the first audit record simple: URL, expected behaviour, observed problem, affected template, responsible person, and a test that will prove the correction. “Improve indexing” is too vague to assign. “Remove the accidental noindex from public service pages and verify the live response” is actionable.
2. Check robots.txt, noindex, and access restrictions separately
These controls do different jobs. Changing one without understanding the others can make a problem harder to diagnose.
| Control | Purpose | Important limitation |
|---|---|---|
| robots.txt | Controls crawler access to specified paths. | A blocked URL can still be known to Google. This is not a reliable removal method. |
| noindex | Asks supporting search engines to exclude a page from their index. | The crawler must access the response to discover the instruction. |
| Password or authentication | Restricts access to private content. | Public pages behind a login are unavailable for normal search crawling. |
| Firewall or bot protection | Filters requests for security. | A misconfigured rule can challenge or block legitimate crawlers. |
Check both the HTML robots meta tag and the HTTP X-Robots-Tag header. If one contains an applicable noindex rule, an index setting elsewhere does not cancel it. When removing an accidental exclusion, correct its source, clear affected caches, and inspect the public response again. See Google’s noindex guidance.
On WordPress, review Settings → Reading → Search engine visibility, then the individual post’s indexing setting in your SEO plugin. Also inspect settings for the whole content type. A public article can inherit an exclusion even when its editor appears otherwise normal.
Keep staging sites protected by authentication. Do not disable security across the live site to solve one blocked request; investigate the rule and verify the crawler before making a targeted exception.
3. Interpret indexing exclusions before trying to fix them
A healthy site does not need every URL indexed. Search Console can list redirected addresses, duplicates, and deliberately excluded pages alongside genuine problems.
| Reported status | What to investigate |
|---|---|
| Excluded by noindex | If exclusion is intentional, leave it. Otherwise find and remove the applicable instruction. |
| Blocked by robots.txt | Check whether the path should be accessible and whether a broad rule catches important pages. |
| Page with redirect | Confirm the destination is the intended replacement. The old URL normally does not need indexing. |
| Alternate page with proper canonical tag | Confirm consolidation is intentional and the preferred page is suitable for search. |
| Discovered, currently not indexed | Review discovery, internal links, server reliability, and unnecessary URL generation. |
| Crawled, currently not indexed | Review content usefulness, duplication, rendering, and whether this page needs a separate URL. |
| Soft 404 | Check whether a successful response contains an error, empty template, or missing main content. |
Use the Page indexing report guidance to interpret the particular issue. Repeated indexing requests do not repair a template or make a duplicate page more useful.
If a page is indexed but receives little traffic, move beyond exclusion settings. Its relevance, search intent, competition, and internal support need investigation. Do not keep changing robots directives to solve a content or ranking problem.
4. Make canonical URLs and duplicate versions agree
A canonical identifies your preferred representative among duplicate or substantially similar pages. Google treats canonical annotations as signals, so it can choose another URL when the surrounding evidence disagrees.
For a distinct public page, a self-referencing canonical is a sensible default. Check that it uses the live HTTPS domain and the correct path. Then compare it with the URL used in internal links, the sitemap, and any redirects.
Test HTTP and HTTPS, plus www and non-www versions, on a real page path. Send alternate versions directly to the preferred HTTPS address, and keep a valid certificate wherever the redirect needs an HTTPS connection. Also check for insecure resources that cause mixed-content problems.
Consider three common situations:
- A tracking parameter creates another address for identical content. The clean page can remain the preferred canonical, and internal links should use that clean address.
- A staging domain appears in every canonical. Fix the template, configuration, or database value producing it, then check several page types after clearing caches.
- Two pages cover related subjects but answer different needs. Keep their independent identities. A pricing guide should not canonicalize to a service page merely because both discuss the same service.
Google’s canonicalization guidance explains how redirects, canonical annotations, and sitemap entries contribute signals.
For translated content, do not point every language version to the English page simply to consolidate authority. Treat useful translations as separate pages; where appropriate, implement and validate reciprocal hreflang annotations for equivalent versions.
5. Help crawlers find the pages that matter
Compare three lists: URLs discovered by a crawl, URLs in the XML sitemap, and public pages recorded in your CMS. A published service page missing from normal navigation and contextual links deserves investigation even if it appears in the sitemap.
Add links where a reader would reasonably need them. Connect a supporting article to the relevant service, and link from a service or established guide to useful explanations. Use real links with an href destination rather than relying only on scripted click actions.
Check that the sitemap contains preferred, indexable URLs that return successful responses. Remove entries for redirects, deleted pages, and content intentionally excluded from search. Update modification dates when meaningful content changes, not simply whenever the sitemap is generated. Google’s sitemap guidance describes the supported signals and limitations.
A sitemap helps discovery; it does not replace useful internal navigation or guarantee indexing. Likewise, an ordinary business site rarely needs an elaborate crawl-budget project. Investigate crawl capacity when evidence points to a problem, especially with large inventories or rapidly multiplying URLs. Google’s crawl-budget guidance explains when that work becomes relevant.
6. Fix broken URLs and preserve useful redirects
Review errors by what the URL is supposed to do. An intentionally removed article without a replacement is different from a live product returning a server error.
- The page should still exist: restore its content or fix the routing problem, then verify a successful response.
- The page has a genuine permanent replacement: use a direct permanent redirect, normally 301 or 308, to that destination.
- The content is gone and has no relevant replacement: return 404 or 410 and remove obsolete internal links.
- The server is failing: investigate hosting, application errors, resource limits, and recent deployments.
Do not redirect every deleted URL to the homepage. That creates a poor destination for visitors and can be interpreted as a soft 404. Avoid long redirect chains by pointing old addresses and internal links directly to the final page. Follow Google’s redirect recommendations.
Before changing a URL, check its search history and available backlink evidence. A shorter slug alone rarely justifies disrupting an established address. Our WordPress broken link guide covers finding links that need correction.
7. Verify rendered content and the mobile version
Modern pages often depend on JavaScript for navigation, product details, or interactive layouts. The important question is whether search systems can reliably access the content those features produce.
Compare the initial response with the rendered page. Look for missing product descriptions, empty article containers, links without destinations, and content that appears only after an interaction. Check failed network requests and browser console errors when an element disappears.
Google can process JavaScript, but rendering is not a reason to make essential content unnecessarily dependent on delayed scripts or blocked resources. Google’s JavaScript SEO documentation explains the processing stages and common pitfalls.
On mobile, verify that the main content, indexing instructions, internal links, and relevant structured data remain consistent. Google primarily uses the mobile version for indexing, as explained in its mobile-first indexing guidance.
For React applications, use our React SEO checklist to test routes, metadata and rendered content before release.
For an Elementor layout, check what a responsive visibility setting actually changes. Content that is already present inside an expandable section differs from content fetched only after a click. Also test the menu, quote form, and product options on a real phone. A layout can look tidy while its main action is unusable.
8. Improve Core Web Vitals at the template level
Core Web Vitals measure loading, responsiveness, and visual stability. Start with real visitor data where available, then use diagnostic tests to identify what needs changing.
| Metric | Good threshold | Investigate |
|---|---|---|
| Largest Contentful Paint (LCP) | 2.5 seconds or less | Slow server responses, delayed main images, or resources blocking the main content. |
| Interaction to Next Paint (INP) | 200 milliseconds or less | Long JavaScript tasks, expensive event handlers, or excessive work during interaction. |
| Cumulative Layout Shift (CLS) | 0.1 or less | Images without reserved space, late banners, or elements moving during loading. |
These thresholds are assessed at the 75th percentile of visits, with mobile and desktop considered separately. See the official Web Vitals definitions.
In PageSpeed Insights, distinguish field data from the Lighthouse lab test. Check whether the field result describes the individual URL or the whole origin. Missing field data does not mean the page passed or failed. A high lab score also does not prove that real visitors have good INP.
Work on the shared cause. If article templates all load a large hero image late, fix how that image is sized and discovered. If a widget blocks interaction across the site, investigate its script rather than compressing unrelated images. Reserve space for media and avoid lazy loading the main image when that delays its appearance.
After changing caching or script optimization, retest forms, consent controls, menus, and checkout. Faster pages are useful only if visitors can still complete their tasks. Google’s Core Web Vitals search guidance places these metrics within the wider page experience picture; a perfect score is not a ranking guarantee.
9. Validate structured data and store-specific URL patterns
Structured data should describe what is actually on the page. Inspect what the theme, SEO plugin, and ecommerce plugin already generate before adding custom markup.
For an article, check the headline, author identity, dates, and page relationship. For a product, check the visible price, currency, availability, and applicable offer details. Fix contradictory output at its source rather than adding another block with different values.
Use Google’s Rich Results Test for supported search features. A passing test establishes neither guaranteed display nor the truth of the supplied information. Follow the structured data policies, and add FAQs for readers rather than an assumed rich-result benefit.
Stores also need rules for filters, sorting, pagination, and product variants. Decide which combinations deserve search visibility before applying blanket exclusions. A useful category can deserve its own indexable page; thousands of near-identical sorting combinations usually serve a different purpose.
Keep paginated product listings discoverable and avoid canonicalizing every page in a sequence to page one when they contain different products. Make sure infinite scrolling has crawlable links to the additional content, following Google’s pagination recommendations. Use Google’s faceted navigation guidance when filters create excessive URL combinations.
Our product page design guide covers the separate task of helping shoppers understand and choose the product.
A WordPress example: a service page excluded after launch
Consider a hypothetical service page that works for visitors but remains absent from search. This is a diagnostic example, not a client case study.
- Confirm the symptom. URL Inspection reports an exclusion, and the current response contains noindex.
- Find the source. The post’s individual SEO setting allows indexing, but a rule for the whole content type excludes it.
- Correct the intended scope. Update the rule for public service pages while leaving private utility pages excluded.
- Clear the affected cache. Check the response as a logged-out visitor and inspect headers as well as HTML.
- Check supporting signals. Confirm a suitable canonical, a sitemap entry, and a relevant incoming link.
- Verify with Google. Run the live test and request indexing if appropriate. Later, review whether Google has processed the changed page.
If the live response still contains noindex, the task is not finished. Another output source or an older cached response may remain. If the instruction is gone but indexing has not changed, that is a different stage of the investigation.
Give one main SEO plugin responsibility for overlapping metadata and sitemap functions. Our WordPress SEO plugin comparison explains selection and configuration; installing another plugin is not the default remedy for every warning.
Protect technical SEO during a redesign or hosting move
A hosting move with unchanged URLs is different from a migration that changes the domain, paths, or content structure. Both need testing, but they do not need the same redirect plan.
Before launch, record important URLs, indexing settings, canonical tags, and existing redirects. After launch, test representative pages over HTTPS, check for staging references, and verify that public content is accessible. Keep a rollback route for changes that break essential functions.
When URLs change, map old pages to their closest relevant replacements and test the redirects. Update internal links and sitemap entries to the final addresses. Google’s site migration guidance recommends keeping redirects for at least a year; useful old addresses may warrant maintaining them longer.
If the project includes rebuilding templates or changing site architecture, our website redesign services cover that broader implementation work.
Does technical SEO help with AI search visibility?
It supports the accessibility and clarity those systems need, but different search products have different crawlers and policies. Do not assume that a setting for one provider controls every AI service.
For Google’s AI Overviews and AI Mode, a supporting page must be indexed and eligible to appear with a snippet. Google says there are no additional technical requirements or special AI schema needed. Its AI features guidance also says you do not need a new AI text file to qualify.
Keep important explanations in accessible page text, maintain accurate structured data, and remove accidental access restrictions. These steps support eligibility. They do not guarantee that an AI answer will quote, cite, or recommend your business.
Turn the audit into verified changes
An audit is useful when someone can act on it. For each issue, record the affected URLs, business consequence, proposed correction, owner, and acceptance test.
For example: “All service pages use the staging domain in their canonical tag. Correct the shared output, clear the cache, and verify the live canonical on the homepage, two service pages, and an article.” That is a clearer task than “Fix duplicate content.”
After implementation, repeat the specific test that found the problem and check other pages using the same template. Separate that immediate verification from later changes in indexing, rankings, and enquiries. Search reports can lag behind the live site.
If you need help deciding which findings matter and implementing the corrections, explore Maple Web Design’s SEO services. Bring the affected URLs and Search Console examples so the discussion starts with the problem your website actually has.
