# Technical SEO: crawling, indexing, speed and the fixes that matter > Technical SEO makes sure search engines can crawl, render, index and understand your pages. The elements that matter, how to audit them and what to fix first. Updated 2026-09-26 · Technical SEO · HTML version: https://getreport.app/guides/technical-seo Technical SEO is the work that makes sure search engines can find, crawl, render, index and understand the pages on your site. It covers the parts of SEO that live in the site itself rather than in the words on the page or the links pointing at it: robots.txt, sitemaps, status codes, redirects, canonical tags, site architecture, JavaScript rendering, mobile support, speed and HTTPS. When technical SEO is broken, good content does not rank because Google never sees it properly; when it is right, nobody notices. This guide is the map for site owners, marketers and developers: what each technical SEO element does, how to check it for free, and the order to fix things in. ## Quick answer - **Technical SEO answers one question: can Google get to this page, read it and index it?** Content and links only count after that. - **The minimum is three things** from Google's Search Essentials: Googlebot is not blocked, the page returns HTTP 200, and it has indexable content. - **The usual culprits** are a leftover `noindex`, a robots.txt block, a canonical pointing somewhere else, redirect chains, broken internal links and content that only appears after JavaScript runs. - **Check one page of each template** (home, category, product or service, article) with the free [SEO audit](https://getreport.app/tools/seo-audit), then use Google Search Console for what only Google knows: which pages it indexed and why not. - **Fix in this order:** indexability, then crawl paths (links, sitemap, redirects), then duplicates and canonicals, then mobile and speed, then structured data and extras. - **Keep watching.** Most technical SEO problems arrive with a release, a plugin update or a migration, not on their own. ## What is technical SEO? SEO is often split into three layers. Technical SEO is the foundation the other two stand on: | Layer | What it covers | Example question | | --- | --- | --- | | **Technical SEO** | Whether search engines can crawl, render and index the page, and how the site is structured | Is this page blocked, redirected, duplicated or invisible without JavaScript? | | **On-page SEO** | The content and HTML of each page: title, headings, text, images, internal links in context | Does this page answer the search, and do its title and headings say so? | | **Off-page SEO** | Signals from other sites: links, mentions, reviews | Do other sites link to and talk about this page? | The line between technical and on-page is blurry: a missing title tag is both. A useful rule is that technical SEO problems usually come from a template, a setting or the server, so they affect many pages at once, while on-page problems are page by page. ### Technical SEO basics: how Google processes a page Every technical SEO factor maps to one step of the path a page takes into Google's index: 1. **Discovery.** Google finds the URL through a link from another page, your XML sitemap or a redirect. 2. **Crawling.** Googlebot requests the URL, if robots.txt allows it and the server answers. 3. **Rendering.** Google runs the page's JavaScript in a recent version of Chromium to see the final content, often some time after the first crawl. 4. **Indexing.** Google decides whether to store the page, which URL to keep when there are duplicates (the canonical), and what the page is about. 5. **Ranking.** Only then do relevance, content quality, links and page experience compete for positions. A problem at any step stops the steps after it. That is why technical SEO comes first: you cannot out-write a `noindex` tag. ## Why technical SEO matters Google's Search Essentials list exactly three technical requirements for a page to be eligible for indexing: Googlebot is not blocked, the page works (it returns an HTTP 200 status code), and it has indexable content. Google also stresses that meeting them makes a page eligible, not guaranteed to be indexed. Most of the damage in practice is quiet. A staging site's "discourage search engines" setting survives the launch. A plugin update adds a second canonical tag. A migration turns one redirect into three. None of these show on the page a visitor sees, and all of them can take pages out of search. Technical SEO is how you catch them. ## Crawlability: can search engines reach your pages? Crawlability is whether a crawler can discover and fetch a URL. It depends on four things. **robots.txt.** The file at `/robots.txt` tells crawlers which paths they may fetch. One stray `Disallow: /` hides a whole site. A blocked URL can still appear in results as a bare link, because blocking stops crawling, not indexing; to keep a page out of search, allow crawling and use `noindex`. The guide [robots.txt: test it before it hides your site](https://getreport.app/guides/robots-txt-before-it-hides-your-site) has safe patterns and the mistakes to avoid. **Internal links.** Google discovers most pages by following links, and it follows `` links, not buttons or scripts that change the URL. A page no other page links to (an orphan) is found late or not at all. **XML sitemaps.** A sitemap lists the URLs you want indexed, with an optional last-modified date. One file holds up to 50,000 URLs or 50 MB uncompressed; larger sites use a sitemap index. Google ignores the `priority` and `changefreq` fields and uses `lastmod` only when it is consistently accurate. [XML sitemap validation](https://getreport.app/guides/xml-sitemap-validation) covers the errors that make Google drop a sitemap. **Server responses.** Repeated 5xx errors or `429 Too Many Requests` make Googlebot slow down, and long redirect chains waste requests. Google's crawl budget documentation says crawl budget is mainly a concern for very large sites (around a million pages or more) or sites with tens of thousands of pages changing daily; for smaller sites the fix is usually elsewhere. See [crawl budget for sites under 10,000 pages](https://getreport.app/guides/crawl-budget-for-sites-under-10000-pages). > **Check: robots.txt allows this page.** A Disallow rule stops search engines from crawling this page, so they cannot read its content or see any updates. The page can still appear in results as a bare URL with no description. > > 1. Remove or narrow the Disallow rule in robots.txt so this URL is allowed for all crawlers. > 2. If the page should stay out of search, allow crawling and use a noindex tag instead; a blocked page cannot be de-indexed. > **Check: The XML sitemap follows the sitemaps.org protocol.** Google reads a sitemap only when it is well-formed XML with absolute URLs and valid dates. One bad file means new pages are found late or not at all, and Search Console reports "couldn't fetch". > > 1. Regenerate the sitemap from your CMS or SEO plugin instead of editing it by hand, and validate it after every change. > 2. Use absolute https URLs in , dates as YYYY-MM-DD in , and split files above 50,000 URLs into a sitemap index. ## Indexability: will Google keep the page? Indexability is whether a crawled page is allowed and suitable to be stored in the index. The blockers, most common first: - **A `noindex` directive** in a robots meta tag or an `X-Robots-Tag` header. Right on thank-you pages and internal search results; a disaster when a whole site launches with it. - **A canonical tag pointing elsewhere.** The canonical tells Google which URL of a set of duplicates to index. It is a hint, not an order, but a wrong one usually wins. See [canonical tags explained](https://getreport.app/guides/canonical-tags-explained). - **A non-200 status.** A 404, 410 or 5xx page is not indexed; a redirect passes indexing to its target. - **Soft 404s.** A page that returns 200 but looks empty or like an error ("no products found") is treated as missing. [Soft 404s](https://getreport.app/guides/soft-404s-what-they-are-and-how-to-fix-them) explains how Google decides. - **Duplicate or thin content.** Google may pick another URL as canonical or decide the page adds nothing new. When a page is missing from Google, work through [why is my page not in Google? The indexability checklist](https://getreport.app/guides/why-is-my-page-not-in-google) in order; it finds the cause fastest. If Search Console reports "Discovered – currently not indexed", Google knows the URL but has not fetched it yet: [what that status means and what to do](https://getreport.app/guides/discovered-currently-not-indexed-what-it-means-and-what-to-do) gives a 20-minute triage. The [robots directives reference](https://getreport.app/guides/noindex-nofollow-complete-reference) lists every directive and where it can go. > **Check: The page can be indexed.** To appear in search, a page must return HTTP 200, carry no noindex directive and be allowed in robots.txt. If any of the three fails, the page is invisible to searchers. > > 1. Open the technical detail to see which condition fails, then fix that one; the individual findings above have the steps. > 2. After the fix, request indexing in Google Search Console to speed things up. > **Check: The page is not set to noindex.** A noindex directive tells Google to drop this page from search results. Unless that is intended, every visit from search is lost. > > 1. Remove noindex from the robots meta tag and from the X-Robots-Tag header, unless the page should stay out of search. > 2. In WordPress, untick Settings → Reading → "Discourage search engines" and check the page's SEO plugin settings. > **Check: Canonical tag points to a valid URL.** The canonical tag asks Google to index that URL instead of this one. If it points to another site, appears twice or leads to an error page, your ranking signals are given away or ignored. > > 1. Point the canonical at this page's own clean URL (same scheme and host, no tracking parameters), and make sure it returns 200. > 2. Keep exactly one canonical tag; if a plugin and the theme both add one, disable one of them. ## Rendering: does the content exist without JavaScript? Google renders JavaScript, but later than the first crawl and with limited resources, and other search engines, AI crawlers and link preview bots often do not render at all. Content that only appears after scripts run, such as product text loaded by an API call or links built by a click handler, can be indexed late, partly or not at all. The safe pattern is to put the main content, the title, the canonical and the links in the HTML the server sends (server-side rendering or static generation) and use JavaScript to enhance it. The guide on [JavaScript-rendered content and Google](https://getreport.app/guides/javascript-rendered-content-and-google) shows how to see what a crawler sees and how to fix it on common frameworks. > **Check: The visible text is present without JavaScript.** Google renders JavaScript later and with a budget, so text that only appears after scripts run can be indexed late or not at all. Other search engines and link previews may never see it. > > 1. Serve the main content in the HTML (server-side rendering or static generation) and use JavaScript only to enhance it. > 2. Check the difference in the technical detail; menus and widgets are fine, headlines and body copy are not. ## Site architecture: how pages connect Site architecture is how your pages are grouped and linked: home to categories, categories to products or articles, and pages to each other. For SEO it decides how quickly crawlers find new pages and how ranking signals flow between them. Good architecture is shallow and logical. Important pages are a few clicks from the home page, every page is linked from at least one relevant page, and URLs reflect the structure without needing to (a URL like `/sofas/grey-three-seater` is readable, but Google does not require folders to match categories). "Three clicks from the home page" is a common rule of thumb, not a Google rule; what matters is that nothing important is buried or orphaned. - **Internal links** carry most of the weight. The guide [internal links: how many, where, and with what anchor text](https://getreport.app/guides/internal-links-how-many-where-anchor-text) gives realistic numbers per page and a 15-minute audit. - **Orphan pages** are pages no other page links to. [Finding orphan pages and linking them back in](https://getreport.app/guides/orphan-pages-finding-and-linking-them) compares your sitemap with a crawl to find every one. - **Breadcrumbs** show the structure to visitors and, with BreadcrumbList markup, to Google: see [breadcrumbs as navigation and structured data](https://getreport.app/guides/breadcrumbs-navigation-and-structured-data). - **URLs** should be short, lowercase, readable and stable. [URL length and structure](https://getreport.app/guides/url-length-and-structure-what-matters) separates what matters from what does not. - **Filters and parameters** on shops can create thousands of near-duplicate URLs. [Faceted navigation and parameter URLs](https://getreport.app/guides/faceted-navigation-and-parameter-urls) keeps them out of the index. > **Check: Internal links.** Internal links are how crawlers and visitors reach the rest of your site. Fewer than 3 leaves the page a dead end; more than 300 dilutes every link and overwhelms visitors. > > 1. Link to related pages from the body text and keep navigation and footer links to what visitors actually need. > 2. For very long lists, split them across pages or use category pages instead of one giant menu. > **Check: Broken links.** A link to a 404 page is a dead end for visitors and a wasted crawl for search engines. Old campaign or product pages are the usual cause. > > 1. Update or remove each link listed in the technical detail; redirect the missing pages if they still get visits. > 2. In WordPress, a plugin such as Broken Link Checker finds these site-wide. ## Redirects, status codes and one version of every URL Every page should have one address. The same page answering at `http://`, `https://`, with and without `www`, and with and without a trailing slash splits signals and invites duplicates. Pick one version and redirect the others in a single hop: [trailing slashes, www and https: pick one](https://getreport.app/guides/trailing-slashes-www-and-https-pick-one). Use permanent redirects (301 or 308) for moved pages and temporary ones (302 or 307) only when the old URL will come back. Googlebot follows up to 10 redirect hops, but every hop costs time for visitors and crawlers, so update internal links to point at the final URL. [Redirects without chains](https://getreport.app/guides/redirects-without-chains) explains each status code, and [404 vs 410 vs redirect](https://getreport.app/guides/404-vs-410-vs-redirect-what-to-do-with-removed-pages) covers what to do with removed pages. > **Check: The URL loads without a redirect chain.** Each redirect is a full request and response before the browser can start loading the page, which slow mobile connections feel most. Google says redirects do not lose ranking value, but Googlebot follows at most 10 hops, and long chains slow crawling and break when one hop changes. > > 1. Point every old URL straight at the final one (a single 301), and update internal links to use the final URL directly. > 2. Look for rules that stack, for example http → https, then non-www → www, then trailing slash; combine them into one rule. > **Check: Only one of www and non-www serves the page.** When the www and non-www addresses both return the page, search engines see two copies of every URL and split links and rankings between them. > > 1. Pick one host as canonical and 301-redirect the other to it, keeping the path (most hosts and CDNs have a one-click setting for this). > 2. Make sure the canonical tag on every page uses the chosen host. ## HTTPS, mobile and speed **HTTPS.** Every page should load over HTTPS, redirect from HTTP, and load no insecure images or scripts. Google lists HTTPS among its page experience considerations. [SSL and TLS checks that matter](https://getreport.app/guides/ssl-tls-checks-that-matter) and [mixed content after HTTPS](https://getreport.app/guides/mixed-content-after-https) cover the details. **Mobile.** Google crawls and indexes sites with its smartphone crawler, and finished moving the last sites to it on 5 July 2024, so the mobile version of a page is the one that counts. That means a viewport meta tag, the same main content, headings, links and structured data on mobile as on desktop, text readable without zooming, tap targets big enough to hit, and no full-screen pop-up on arrival. Google retired its Mobile-Friendly Test and Search Console's Mobile Usability report in December 2023, so checking this is now up to you. The [mobile SEO checklist](https://getreport.app/guides/mobile-seo-checklist) turns it into 24 checks in six groups (crawl access, content parity, layout, taps and pop-ups, mobile speed and m-dot extras) with a free way to run a mobile SEO audit on one page per template. **Speed.** Google says Core Web Vitals are used by its ranking systems, as one part of page experience, while relevance comes first. Technical SEO and page speed overlap on the server side: slow responses also slow crawling. The [page speed guide](https://getreport.app/guides/page-speed) is the map for measuring and improving it. > **Check: The site is served over HTTPS.** Browsers label HTTP pages "Not secure" and Google uses HTTPS as a small ranking signal. Anyone on the network can read or alter what visitors see. > > 1. Get a certificate (Let's Encrypt is free) and enable HTTPS on your host. > 2. Redirect every http:// URL to https:// with a 301. > **Check: Viewport meta tag is present.** Without a viewport tag, phones render the page at desktop width and shrink it. Google indexes the mobile version first, so this hurts rankings directly. > > 1. Add in . ## Structured data, international sites and AI crawlers **Structured data.** Schema.org markup in JSON-LD tells search engines what a page is about in a machine-readable way: a product with a price, an article with an author, a business with an address. It can make pages eligible for rich results, though Google never guarantees them. Start with [JSON-LD basics](https://getreport.app/guides/json-ld-basics) and validate with [schema markup validation](https://getreport.app/guides/schema-markup-validation). **International sites.** Sites in several languages or countries need `hreflang` annotations so Google shows each visitor the right version. Every language version must link back to the others, or Google ignores the set: see [hreflang return links](https://getreport.app/guides/hreflang-return-links) and [subfolder vs subdomain vs ccTLD](https://getreport.app/guides/international-sites-subfolder-vs-subdomain-vs-cctld). **AI crawlers.** Crawlers from AI companies read robots.txt too, and you can allow or block them separately from Googlebot. Blocking Google-Extended, for example, controls use of your content for Google's AI models without affecting Google Search. The guide to [AI crawlers and robots.txt](https://getreport.app/guides/ai-crawlers-and-robots-txt) lists who fetches your site and how to decide. > **Check: Every hreflang alternate links back to this page.** hreflang only works when every version lists every other version, including itself. An alternate that does not point back makes Google ignore the pair, so visitors get the wrong language. > > 1. On each alternate page, add a for this page and for itself. > 2. Generate the tags from one list (CMS, plugin or the XML sitemap with xhtml:link) so every page carries the same set. > **Check: JSON-LD syntax.** A JSON-LD block with a syntax error is ignored completely, so Google reads no structured data from it. One stray comma or missing quote costs the whole block. > > 1. Open the technical detail to see the parser message and the block number. > 2. Paste the block into a JSON validator, fix the character it points at, and run this check again. ## How to do a technical SEO audit A technical SEO audit checks each of the areas above on the pages that matter. You do not need to crawl every URL to find most problems, because they come from templates: fix the product template and every product page improves. In outline: 1. **Pick one page per template:** home, a category or listing page, a product or service page, an article and a landing page. 2. **Audit each one** for indexability, canonical, robots, status, redirects, headings, links, mobile and speed. 3. **Check the site-wide files:** robots.txt, the XML sitemap and the http/www redirects. 4. **Open Google Search Console** for what only Google knows: the Page indexing report (which pages are indexed and why others are not), URL Inspection for a single page, and the Core Web Vitals report. 5. **Fix by impact:** anything that hides pages from Google first, then crawl paths, then duplicates, then speed and extras. > **Free tool:** [Free SEO checker and SEO audit for any page](https://getreport.app/tools/seo-audit): Free SEO audit of any page: titles, headings, canonical, robots.txt, sitemaps, indexability and broken links, each with a plain-language fix. No sign-up. The SEO audit checks one page per run, together with the site-wide files it depends on: title, description, headings, canonical, robots directives, hreflang, language and viewport tags, robots.txt, the XML sitemap, redirects, www consistency and broken links. Every finding has a plain-language fix and is ordered by the points it costs, so the top of the list is what hides the page from Google. It measures only your site, so it does not show rankings, keywords or backlinks; Search Console, which is free, covers those for your own site. A crawl of up to 500 pages with duplicate titles, orphan pages and a sitemap diff is a funded unlock: it switches on for everyone once donations cover it. ### Auditing a single page For one URL, the [on-page SEO checklist](https://getreport.app/guides/one-page-seo-audit) gives 12 checks in order of impact, from indexability and the title to links, images and structured data, and shows how to audit a page in about a minute and read the score. It is the fastest way to learn what a technical audit looks for. ### The full audit checklist The [SEO audit checklist](https://getreport.app/guides/seo-audit-checklist) turns the outline above into 45 checks in nine groups, from indexing and the site-wide files to templates, links, rendering, mobile, speed and structured data. Each row says how to verify the check for free and what counts as a pass, and the groups are in order of impact, so you can stop after the first two when time is short. It is the whole-site companion to the one-page audit: you run the one-page audit once per template as part of it, and add what no single page shows, such as whether the sitemap and robots.txt agree, whether every URL variant collapses into one, and what Google has indexed. ### Writing it up An audit only helps if someone acts on it. [The SEO audit report template](https://getreport.app/guides/seo-audit-report-template) gives the sections a report needs (a three-sentence summary, scope, a small scorecard, findings with evidence, owners and a plan), a Markdown template to copy and a filled-in sample. It also explains honestly where a getReport report link fits: as the evidence for each template, not as the whole audit. ### Common technical SEO issues Most audits find the same problems again and again: pages accidentally set to `noindex`, canonicals pointing to the wrong URL, broken internal links, redirect chains after a migration, duplicate titles across a template, sitemaps listing redirected or removed URLs, missing viewport tags on old templates, and content that needs JavaScript. [The 15 most common technical SEO issues](https://getreport.app/guides/technical-seo-issues) takes each one in order of damage (first what hides pages, then what wastes crawling, then what confuses Google) with the Search Console status that reveals it, the getReport finding that points at the cause, and the fix. It ends with how to prioritise by pages affected and how to stop the same issues returning with the next release. ### Online shops Shops fail differently from other sites because their templates multiply: filter and sort parameters create thousands of URLs, one product sits under several categories, products sell out and come back, and product structured data must match the visible price. The [ecommerce SEO audit](https://getreport.app/guides/ecommerce-seo-audit) is the shop-specific layer on top of the checklist: indexed pages against products sold, filters and parameters, category and product templates, variants, out-of-stock and discontinued products, product schema, speed per template, and keeping cart, checkout and internal search out of the index. [Faceted navigation and parameter URLs](https://getreport.app/guides/faceted-navigation-and-parameter-urls) covers the filters in depth. ### What an audit costs A technical audit can be done for free with Search Console and a free checker; freelancers and agencies charge for the judgement, the prioritisation and the strategy around it. The price mostly follows the hours: site size, number of templates and languages, and whether content, links and competitors are in scope. [SEO audit cost: what you pay for, and what you can do free](https://getreport.app/guides/seo-audit-cost) compares the free self-audit, automated tools, freelancers and agencies, with the rate ranges from a published survey of SEO providers, what a good paid audit should deliver, and the red flags in a quote. The short version: do the free pass first, then pay for the questions it leaves open. ## Launches, migrations and ongoing monitoring Technical SEO breaks most often when something changes. Three moments deserve a checklist: **Before a launch.** New sites and redesigns go live with staging settings more often than you would think. [The website launch checklist](https://getreport.app/guides/pre-launch-website-checklist) has 30 checks, from `noindex` and redirects to forms and backups, and a launch-day sequence. **During a migration.** A domain, HTTPS or CMS move changes every URL at once. The [site migration checklist](https://getreport.app/guides/site-migration-checklist-domain-https-cms) covers redirect maps, what to check on launch day and how to watch the first weeks. **Between audits.** [SEO monitoring](https://getreport.app/guides/monthly-site-health-routine) covers what to watch between audits: the free alerts to switch on, and a 30-minute monthly routine with report links to compare month on month. Search Console also emails you about new indexing problems once your site is verified there. > **Free tool:** [Monitor website for changes: email alerts](https://getreport.app/tools/change-monitor): Monitor a website for changes for free and get one email with the added and removed lines when its text changes. It switches on once donations cover it. The change monitor is built for the moments between audits: it reads a page once a day and emails you the lines of visible text that were added or removed, for up to 5 pages per email address. It is a funded unlock: it switches on for everyone once donations cover the daily checks, and until then the tool page shows an example alert. ## Platform notes **WordPress.** Check that "Discourage search engines from indexing this site" is off after launch ([what that setting does](https://getreport.app/guides/wordpress-discourage-search-engines)), use post-name permalinks ([WordPress permalinks](https://getreport.app/guides/wordpress-permalinks)), keep attachment pages out of the index ([attachment pages](https://getreport.app/guides/wordpress-attachment-pages)) and run only one SEO plugin ([Yoast and Rank Math together](https://getreport.app/guides/duplicate-seo-plugins-yoast-and-rank-math-together)). **Shopify.** Shopify generates robots.txt, the sitemap and canonical tags for you, and products are reachable under collection URLs that canonicalise to the main product URL. Your levers are theme templates, apps that inject content, and how you link collections. See [Shopify: what you can fix and what you cannot](https://getreport.app/guides/shopify-what-you-can-and-cannot-fix). **JavaScript frameworks.** React, Vue and similar sites need server-side rendering or static generation for the main content, and real `` links between pages. [JavaScript-rendered content and Google](https://getreport.app/guides/javascript-rendered-content-and-google) covers the checks. **Cloudflare and other CDNs.** Bot protection that challenges unknown visitors can block legitimate crawlers too. After enabling it, confirm in Search Console's URL Inspection that Googlebot still gets your pages; [your server logs](https://getreport.app/guides/server-log-analysis-googlebot-and-ai-bots) show what crawlers actually request. ## Common mistakes - **Blocking a page in robots.txt to remove it from Google.** Google cannot see a `noindex` on a page it may not crawl. Allow crawling and use `noindex`, or remove the page. - **Canonical tags pointing at the home page or at page 1** of every paginated series. Each page should usually canonicalise to itself. - **Redirecting every removed page to the home page.** Google often treats that as a soft 404. Redirect to the closest replacement or return 404 or 410. - **Leaving redirected and removed URLs in the sitemap.** A sitemap should list only indexable, 200-status, canonical URLs. - **Auditing only the home page.** Templates carry the problems; check one page of each. - **Fixing warnings before blockers.** A perfect meta description does nothing on a page with `noindex`. Work from the top of the findings list. ## Questions people ask ### What is technical SEO? Technical SEO is the part of SEO that makes sure search engines can crawl, render, index and understand your pages. It covers robots.txt, XML sitemaps, status codes, redirects, canonical tags, site architecture, JavaScript rendering, mobile support, speed and HTTPS. It does not make a page relevant on its own, but without it, even the best content may never appear in search. ### What is the difference between technical SEO and on-page SEO? Technical SEO is about whether search engines can reach and index a page; on-page SEO is about whether the page's content answers the search. Technical issues usually come from templates, settings or the server and affect many pages at once, like a noindex tag or a redirect chain. On-page work is page by page: the title, headings, text and images. ### How do I do technical SEO on my own site? Start with one page of each template and a free audit. Check that each page returns 200, has no noindex, is allowed in robots.txt and has a correct canonical. Then verify your sitemap and redirects, fix broken internal links, and confirm mobile and speed. Use Google Search Console's Page indexing report to see which pages Google has left out and why. ### What are the most important technical SEO factors? Indexability comes first: a 200 status, no noindex, no robots.txt block and a correct canonical. Next come crawl paths, meaning internal links, an accurate XML sitemap and single-hop redirects. After that, mobile-friendliness, HTTPS and Core Web Vitals, then structured data and hreflang where relevant. Fix them in that order, because each one only helps once the ones before it are right. ### What is the difference between crawlability and indexability? Crawlability is whether a search engine can reach and fetch a page; indexability is whether it may and will store that page in its index. A page blocked by robots.txt is not crawlable. A page with a noindex tag is crawlable but not indexable. A page needs both, plus content Google considers worth keeping, to appear in search results. ### Is page speed part of technical SEO? Yes, partly. Google uses Core Web Vitals from real Chrome visitors in its ranking systems, and the server side of speed, such as response time and redirects, also affects how efficiently Googlebot crawls a site. Speed is a smaller factor than indexability and relevance, so fix pages that cannot be indexed first, then work on speed where the field data fails. ### How long does technical SEO take to show results? Days to a few months, depending on the fix. Removing a noindex or a robots.txt block can bring a page back within days once Google recrawls it, which you can speed up with URL Inspection in Search Console. Site-wide changes such as a migration or a new internal linking structure take weeks to months, and Core Web Vitals data covers a rolling 28 days. ### Do I need a developer for technical SEO? Not for finding problems and fixing many of them. Settings such as noindex, canonical tags, sitemaps, redirects and permalinks are usually available in your CMS or SEO plugin. You need a developer for template changes, server configuration, JavaScript rendering and speed work in the code. Send them the report link and the specific findings, so they know exactly what to change.