Technical SEO Checklist: 10 Fixes for Better Rankings

Technical SEO helps search engines discover, crawl, understand, render, and index the pages you actually want people to find. A website can have excellent content and authoritative backlinks but still struggle in organic search if important pages are blocked, duplicated, extremely slow, or buried behind poor architecture. Technical optimization removes these obstacles so stronger content has a better opportunity to compete. It includes everything from robots.txt and XML sitemaps to canonical tags, redirects, mobile usability, internal links, and structured data. The goal is not to make a website technically complicated. The goal is to create a clean, predictable foundation that works reliably for both users and search engines.

A useful technical SEO checklist should prioritize problems according to impact instead of treating every warning inside an audit tool as equally urgent. A broken canonical on thousands of valuable pages deserves more attention than a minor formatting issue on one unimportant URL. Likewise, fixing indexation problems can produce greater value than spending days chasing a perfect performance score that users already experience comfortably. The ten fixes below cover the technical areas that most websites should review before investing aggressively in new content or backlinks. Each section explains what to check, why it matters, and how to approach the problem without creating unnecessary complexity. Regular technical maintenance can protect rankings while making future SEO growth easier to scale.

1. Make Sure Search Engines Can Crawl Important Pages

Crawlability is the starting point of technical SEO because a search engine generally needs to discover and access a page before it can evaluate that page for indexing. Important URLs should be reachable through ordinary internal links rather than depending entirely on search forms, scripts, or isolated XML sitemap entries. A crawler moving through your website should be able to follow navigation from major sections toward categories, services, products, articles, and other valuable destinations. Pages buried behind many unnecessary clicks can receive weaker internal visibility. Begin an audit by identifying whether commercially important pages are actually accessible. Strong crawl paths make discovery more reliable for both new and updated content.

Internal navigation plays a major role in crawlability because search engines use links to move between URLs. A page with no internal links pointing toward it is commonly called an orphan page. It may still be discovered through a sitemap or external backlink, but relying on those methods creates unnecessary uncertainty. Important pages should receive relevant links from categories, menus, articles, breadcrumbs, or other useful sections. Internal linking should reflect how visitors naturally move through the website. When both users and crawlers can reach a page logically, the architecture becomes much easier to understand and maintain.

JavaScript can create crawlability problems when important links or content depend on interactions that crawlers cannot reliably access. Modern search engines can render substantial JavaScript, but unnecessary dependence on client-side execution can still complicate discovery. Key navigation should use crawlable links rather than requiring buttons that trigger hidden routing without clear URLs. Developers should test what a rendered crawler can actually see instead of assuming the browser experience tells the full story. This is especially important for modern single-page applications and ecommerce filters. Critical content should remain accessible even when sophisticated interface features are layered on top.

Large websites should also think about crawl efficiency. Ecommerce sites, marketplaces, and publishers can accidentally generate enormous numbers of parameterized, filtered, duplicate, or low-value URLs. Search engines may spend considerable crawl activity repeatedly visiting those variations while valuable categories receive less attention. Crawl budget is rarely a major issue for small websites, but URL explosion can create genuine problems at scale. Controlling duplicate paths, faceted navigation, and unnecessary calendar or archive URLs helps focus crawling. The objective is not blocking everything possible; it is making the useful parts of the website easier to reach.

A technical crawl should ultimately answer a simple question: can search engines move through the website in approximately the same logical way a knowledgeable visitor would? If the answer is no, identify where the path breaks. Fix orphan pages, inaccessible navigation, unnecessary depth, broken links, and duplicate crawl routes before expanding content production. Crawling problems are particularly important during redesigns because new templates can unintentionally remove links that previously supported important sections. Rechecking crawlability after development changes helps catch these issues early. A website that is easy to crawl gives every other SEO effort a stronger foundation.

2. Fix Indexing and Noindex Problems

Crawling and indexing are related but different processes. A search engine may successfully crawl a page without deciding to include that page in its searchable index. Technical SEO therefore needs to verify not only whether important pages are accessible but also whether they are eligible and appropriate for indexing. Accidental noindex directives are one of the most damaging problems because they directly signal that a page should not appear in search. This can happen after staging environments, redesigns, template changes, or plugin configurations. Important commercial and informational pages should be reviewed regularly for unexpected indexation directives.

Not every URL should be indexed, however. Search results pages, login areas, account dashboards, internal tools, duplicate filters, checkout steps, and low-value utility pages may have little reason to appear publicly in search. Technical SEO is partly about deciding which URLs deserve indexation and which should remain outside the search index. Allowing every generated URL to index can create thin or duplicate sections that dilute site quality. A clean index should emphasize useful pages with distinct search value. Indexation strategy therefore requires intentional selection rather than trying to maximize the total number of indexed URLs.

Indexing reports can reveal patterns when search engines discover pages but choose not to index them. A few excluded URLs are normal, but large unexpected groups deserve investigation. Pages may be duplicates, poorly linked, extremely thin, canonicalized elsewhere, blocked by directives, or judged too similar to stronger URLs. Instead of attempting to force every excluded page into the index, ask whether the page genuinely deserves independent visibility. Sometimes consolidation is the better solution. Indexation problems often expose deeper content and architecture issues rather than a simple technical switch that needs changing.

Soft 404s and thin pages can also affect index quality. A page may return a successful server response while containing almost no useful content, perhaps because a product was removed or a template failed. Search engines can interpret such pages as effectively nonexistent even though the server reports that everything is fine. Review important pages for missing products, broken templates, empty categories, and failed dynamic content. If a page no longer has value and no relevant replacement exists, returning an appropriate not-found response may be cleaner. Technical accuracy helps search engines understand what actually exists.

Indexation auditing should connect directly with business priorities. A website does not need every tag archive or filtered page indexed if those URLs generate no meaningful search value. Instead, focus on whether services, categories, products, important articles, and other strategic pages appear consistently. Compare the number of valuable pages you expect to be indexed with what search engines actually show. Unexpected gaps should be investigated promptly. A technically healthy website maintains a deliberate index in which important pages are available and unnecessary duplicates remain controlled.

3. Correct Canonical Tags and Duplicate URLs

Canonical tags help search engines understand which URL should be treated as the preferred version when several addresses contain the same or very similar content. Duplicate versions commonly appear through tracking parameters, filters, print pages, alternate navigation paths, and ecommerce sorting options. Without consistent canonicalization, ranking signals may become divided across several URLs. Search engines can often choose their own preferred version, but website owners should make that decision as clear as possible. A canonical tag is therefore a useful consolidation signal rather than a method for creating duplicate pages without consequences. Important indexable pages commonly use self-referencing canonicals to reinforce their preferred address.

Canonical tags should point toward relevant, valid, indexable URLs. A common technical mistake is canonicalizing a page toward a redirected, broken, blocked, or nonindexable destination. This creates conflicting signals because the website claims one URL is preferred while simultaneously making that URL unsuitable for search. Canonical chains should also be avoided where page A points to B and B points to C. A cleaner implementation points directly toward the final preferred URL. Search engines can resolve many imperfect configurations, but technical SEO should reduce ambiguity rather than expecting crawlers to repair it automatically.

Internal linking should agree with canonical choices. If every product link points to a parameterized version while the canonical tag points toward a cleaner URL, the website is sending mixed signals. Update navigation, breadcrumbs, category links, and editorial links so they reference preferred canonical addresses directly. XML sitemaps should also contain canonical URLs rather than alternate versions. Consistency across these systems makes consolidation easier. Canonical tags are most effective when they confirm an architecture that is already clean rather than trying to compensate for widespread internal inconsistency.

Duplicate content can also occur across HTTP and HTTPS versions, www and non-www hosts, uppercase and lowercase paths, or URLs with and without trailing slashes. Server configuration should establish one preferred form and redirect alternatives when they are not needed independently. This is generally stronger than leaving every variation accessible and depending entirely on canonical tags. Similar problems can occur after migrations when both old and new domains remain indexable. Technical audits should therefore look beyond page content and check whether multiple structural versions of the site exist.

Do not use canonical tags to solve unrelated content strategy problems. Two pages targeting different intents should not be canonicalized together simply because they share several paragraphs. Likewise, a weaker page should not automatically canonicalize to a stronger one unless they genuinely represent duplicate or substantially equivalent content. If two pages unnecessarily compete for the same intent, consolidation and redirects may be more appropriate. Canonicalization works best when it expresses a true preferred version. Correct canonical tags help search engines concentrate signals instead of guessing which duplicate URL matters most.

4. Clean Up Redirects, Broken Links, and 404 Errors

Redirects are essential when URLs move permanently, but unmanaged redirects can become a technical SEO problem of their own. A 301 redirect is generally appropriate when an old page has a clear permanent replacement. The destination should be the most relevant page available rather than simply the homepage. If an old technical SEO guide is replaced by a newer comprehensive guide, redirecting to that resource helps both users and search engines continue their journey. Relevant redirects can preserve much of the value associated with an established URL. They also prevent external backlinks from sending visitors toward dead pages.

Redirect chains should be minimized because each unnecessary hop adds complexity. A URL might redirect from A to B after one redesign and then from B to C after another. Browsers and crawlers can usually follow the chain, but users experience additional requests and technical teams become more likely to create loops or broken paths later. Update internal links to point directly toward the final destination. Where practical, old redirect rules should also be consolidated so A goes straight to C. Regular cleanup keeps legacy migrations from accumulating into a confusing redirect network.

Broken internal links deserve attention because they send both users and crawlers toward pages that no longer exist. Large content libraries often accumulate broken links as articles are deleted, products disappear, or URLs change. Crawl the site periodically and identify internal links returning 404 or other error responses. Update them to relevant live destinations when appropriate or remove the link if no replacement exists. Fixing internal broken links is usually straightforward and improves navigation immediately. External broken backlinks can sometimes be recovered through redirects when the destination content has moved.

Not every 404 page represents an SEO emergency. If a URL should no longer exist and has no useful equivalent, returning a proper 404 or 410 response can be perfectly acceptable. Problems arise when valuable pages disappear accidentally or thousands of legitimate internal links point toward missing URLs. Custom 404 pages can help users find navigation or search options, but they should still return the correct HTTP status rather than pretending to be normal content. Search engines need an accurate signal that the requested resource is unavailable. Trying to redirect every missing URL to the homepage can create confusing experiences.

Redirect auditing becomes especially important during website migrations. Before launch, collect valuable old URLs from crawls, analytics, backlinks, and sitemaps, then map them to the most relevant new pages. After launch, test those redirects and monitor unexpected 404s. Avoid multi-step chains caused by redirecting through previous versions of the site. Migration mistakes can cause significant organic losses even when the redesigned content looks excellent. Clean redirect management protects historical SEO value while keeping users connected with the information they intended to reach.

5. Optimize Your XML Sitemap

An XML sitemap is a structured list that helps search engines discover URLs a website considers important. It is particularly useful for large sites, new websites with few backlinks, frequently updated publishers, and ecommerce stores where products can appear deep within navigation. A sitemap does not guarantee indexing or rankings. Search engines still evaluate quality, duplication, crawl signals, and relevance independently. Its purpose is discovery and organization. A clean sitemap should therefore contain pages you genuinely want crawled and considered for indexing rather than every URL your CMS happens to generate.

Only canonical, indexable URLs should generally appear in the main sitemap. Redirected pages, broken URLs, noindex pages, duplicate parameters, and alternate canonical versions create unnecessary noise. If a URL is important enough to include in a sitemap, the rest of the website should treat it as an important preferred page as well. Large inconsistencies between sitemaps and canonical tags can make technical diagnostics more difficult. Audit sitemap entries periodically, especially after migrations or CMS changes. Automated sitemap generation is helpful only when the underlying rules are configured correctly.

Large websites can divide URLs into sitemap indexes according to type or section. Products, categories, articles, images, and localized pages may each have separate sitemap files. This makes monitoring easier because problems can be isolated to a particular template or section. If thousands of product URLs suddenly stop being indexed, the product sitemap provides a focused dataset for investigation. Sitemaps should remain within technical size limits, which most modern platforms handle automatically. The practical benefit of separation is visibility rather than an inherent ranking advantage.

The lastmod field can be useful when it accurately reflects meaningful content updates. It should not be manipulated so every page appears to change every day when nothing substantial has happened. Reliable modification information can help search engines prioritize recrawling, particularly on large or frequently updated sites. CMS systems should update the value when content genuinely changes rather than whenever a server process runs. Accuracy matters because signals become less useful when they are constantly overstated. Technical SEO should prefer trustworthy metadata over attempts to create artificial freshness.

Sitemaps should complement internal linking, not replace it. A valuable page that exists only in an XML sitemap but receives no meaningful internal links remains poorly integrated into the website. Search engines may discover it, yet the architecture gives little indication of why the page matters. Every strategic URL should have a logical place within navigation or contextual linking. Use the sitemap as an additional discovery layer and diagnostic tool. When sitemaps, canonicals, internal links, and indexation preferences all align, search engines receive a much clearer picture of the site.

6. Review Robots.txt Without Blocking Valuable Content

The robots.txt file provides crawl instructions for compliant search engine bots and can help control access to certain URL patterns. It is commonly used to discourage crawling of areas such as internal search results, administrative paths, or low-value parameter spaces. However, robots.txt is powerful enough to create serious problems when configured incorrectly. Blocking an entire important directory can prevent crawlers from accessing valuable pages or resources. Every major technical audit should therefore include a review of the file. Small changes should be tested carefully before deployment.

Robots.txt controls crawling rather than guaranteeing deindexation. This distinction is important because blocking a URL does not automatically mean that the URL can never appear in search results. If search engines discover the address through external or internal links, they may know the URL exists even when they cannot crawl its content. If the goal is preventing a page from appearing in search, an appropriate indexation strategy should be used instead. Crawlers generally need access to see certain page-level directives. Technical teams should choose the control that matches the actual objective.

Avoid blocking CSS, JavaScript, images, or other resources required for search engines to render important pages accurately. In older SEO practices, websites sometimes blocked large resource folders because those files were not considered content. Modern search engines evaluate rendered pages, so critical resources should normally remain available. If a crawler cannot load the scripts or styles necessary to understand the page, testing may show a different experience from what users receive. Render important templates during audits to identify blocked resources. Technical SEO should support accurate interpretation rather than stripping crawlers down to raw text unnecessarily.

Development and staging environments require special care because teams often use robots.txt to discourage crawling before launch. This can be useful, but staging sites containing sensitive or unfinished content should ideally have stronger access controls as well. The major risk comes when staging directives are accidentally carried into production. A redesign can launch successfully from a visual perspective while the new site remains blocked from crawling. Pre-launch checklists should therefore verify robots.txt, noindex directives, canonicals, and authentication settings. These simple checks can prevent severe organic traffic losses.

Keep robots.txt rules as simple as the website allows. Complex patterns created over many years can become difficult for new developers to understand and may block unexpected URLs. Document why important rules exist so future teams do not remove them blindly. Revisit the file when site architecture changes because paths that were once irrelevant may later host valuable content. Robots.txt should support crawl efficiency without becoming a mysterious collection of legacy instructions. Simpler, well-documented rules are easier to test and safer to maintain.

7. Improve Core Web Vitals and Page Performance

Page performance affects user experience because visitors expect websites to load and respond without unnecessary delay. Core Web Vitals provide a useful framework for evaluating loading performance, responsiveness, and visual stability. The three key concepts are whether important content appears promptly, whether user interactions respond quickly, and whether elements remain visually stable instead of shifting unexpectedly. Strong performance does not guarantee rankings, but poor performance can reduce user satisfaction and conversions. Technical SEO should therefore improve real experiences rather than chase scores without understanding what users encounter.

Images are one of the most common performance problems. Large photographs uploaded directly from cameras or design files can add several megabytes to a page unnecessarily. Compress images, serve them at appropriate dimensions, and use efficient formats supported by the site. Responsive image techniques can deliver different sizes based on the visitor’s screen instead of sending desktop-sized assets to every phone. Lazy loading is useful for images below the visible portion of the page. Important hero images should be handled carefully so loading optimization does not accidentally delay the page’s main visual content.

JavaScript can create additional performance costs when websites rely on large frameworks, advertising scripts, analytics, chat tools, personalization, and marketing pixels simultaneously. Each script may appear harmless by itself, but the combined processing can delay interaction. Audit third-party tools and remove those no longer delivering enough value to justify their cost. Developers should also reduce unnecessary code and split large bundles where appropriate. Performance should be measured on realistic mobile devices and connections rather than only powerful office computers. Real users may experience the page very differently from development teams.

Layout shifts occur when content unexpectedly moves while the page is loading. A visitor may attempt to click a button only for an advertisement, image, or banner to appear above it and push the interface downward. Reserving dimensions for images, embeds, advertisements, and other dynamic elements helps reduce these shifts. Fonts should also be handled carefully so late-loading typography does not substantially change layout. Visual stability improves usability even when total loading time remains similar. Technical performance is about predictability as much as speed.

Performance optimization should be prioritized according to templates and business impact. Fixing the product template used across ten thousand pages is usually more valuable than perfecting one low-traffic blog post. Measure field data where available because laboratory tests cannot reproduce every visitor environment. Improvements should also be evaluated alongside conversion performance. A technically faster page that breaks important functionality is not an improvement. The goal is a fast, stable, functional experience that supports both users and search visibility.

8. Make Mobile Usability a Technical Priority

Mobile SEO matters because users increasingly research products, services, and information through smartphones, even in B2B industries traditionally associated with desktop browsing. A responsive website should adapt naturally to different screen sizes without hiding important content or functionality. Users should be able to read text, navigate menus, complete forms, and interact with primary features comfortably. A page that technically fits on mobile but requires constant zooming or precise tapping still provides a poor experience. Technical audits should therefore test usability rather than merely confirming that a responsive stylesheet exists.

Content parity is important because mobile users should receive the meaningful information available on desktop. Some older mobile implementations removed sections, links, or structured content to simplify smaller screens. This can weaken both user experience and search understanding when important material disappears. Responsive design allows the same essential content to remain available while changing its presentation. Collapsible sections can be useful when they improve usability, but they should not be used to hide information users genuinely need. Mobile layouts should prioritize clarity without becoming stripped-down versions of the real site.

Navigation deserves special attention because complex desktop menus can become difficult to use on small screens. Important categories, services, products, and account functions should remain easy to reach. Hamburger menus can work well when organized logically, but avoid hiding critical pathways behind several layers of interaction. Breadcrumbs can provide additional context on deep pages. Search functionality also becomes valuable on large ecommerce and publishing sites. Mobile navigation should help users move quickly rather than requiring them to remember where content sits within a complicated hierarchy.

Forms frequently create mobile conversion problems. Fields may be too small, labels unclear, keyboards inappropriate, or forms much longer than necessary. B2B lead forms should request only information genuinely needed for qualification at that stage. Ecommerce checkout forms deserve even more attention because small usability problems directly affect revenue. Use suitable input types so phones can display relevant keyboards for email addresses, numbers, and other data. Clear validation messages prevent users from repeatedly guessing what went wrong. Technical SEO becomes more valuable when performance improvements support conversions as well as crawling.

Testing should cover real devices, not just desktop browser resizing. Different phones, browsers, screen dimensions, and connection speeds can expose issues that development emulators miss. Check sticky banners, cookie notices, popups, chat widgets, and navigation because these elements can consume a large portion of small screens. Intrusive overlays can make content difficult to access immediately after search users arrive. Mobile-first thinking should be built into design and QA processes rather than added after launch. A site that works naturally on small screens creates a stronger experience for a large share of search visitors.

9. Strengthen Internal Linking and Site Architecture

Internal linking is both an on-page and technical SEO tool because links establish pathways through the site and communicate relationships between pages. Important commercial URLs should not depend only on top navigation for internal authority. Relevant blog articles, categories, guides, and supporting pages can link toward them contextually. These connections help users discover logical next steps while showing search engines how topics fit together. A website with hundreds of disconnected pages is harder to understand than one organized into meaningful clusters. Internal links create the structure that turns individual URLs into a coherent site.

Anchor text should describe the destination clearly without becoming repetitive or manipulative. A link saying “technical SEO audit” gives users more information than “click here,” but every internal link does not need the same exact-match keyword. Natural variations make content easier to read and can describe different aspects of the destination. Avoid adding dozens of links merely to increase internal-link counts. Each connection should have a useful reason. Internal linking works best when relevance determines placement rather than a fixed quota applied to every page.

Site depth should also be considered. Important categories and service pages should generally be reachable within a reasonable number of clicks from major navigation points. Excessively deep architecture can make discovery slower and suggests that important pages have little prominence. Large ecommerce sites should use category hierarchies, breadcrumbs, and internal links to expose deeper products efficiently. Publishers can create topic hubs connecting important resources. The exact number of clicks is less important than ensuring valuable content is not buried unnecessarily. Architecture should reflect importance and user needs.

Orphan-page audits can uncover content that has fallen outside the internal structure. These pages may have been created during old campaigns, imported from previous websites, or accidentally removed from navigation. Some may deserve new internal links, while others should be consolidated or removed. Comparing crawl data with XML sitemaps and analytics can help identify URLs that exist but receive no navigational support. Orphans are especially common on sites that have published content for many years. Regular cleanup keeps the information architecture intentional.

Internal linking should be reviewed when content is updated or new pages are published. A new comprehensive guide can receive links from older relevant articles, while the new page can link back toward useful established resources. This creates immediate integration instead of waiting months for someone to remember the page exists. Content teams can include internal-link requirements within briefs and publishing checklists. Technical SEO specialists can then audit the broader pattern periodically. Strong internal architecture improves crawlability, topical relationships, user journeys, and the distribution of authority throughout the site.

10. Add and Validate Relevant Structured Data

Structured data provides machine-readable information that helps search engines understand certain types of content and entities more clearly. Schema markup can describe products, organizations, breadcrumbs, articles, events, recipes, job postings, and other supported content types. The purpose is to represent information that genuinely exists on the page rather than inserting hidden claims purely for SEO. Correct structured data can make pages eligible for certain enhanced search appearances when search engines choose to show them. Eligibility does not guarantee a rich result. Structured data should therefore be treated as clarification, not a ranking shortcut.

Choose schema types according to actual page content. A product page can include product-related information when the page genuinely represents an individual product, while an article can use appropriate article markup. Breadcrumb schema can help communicate hierarchy across many website types. Local businesses can describe relevant organization information where appropriate. Avoid applying every available schema type to every page simply because a plugin makes it possible. More markup is not automatically better. Accurate markup aligned with visible content is more useful than an oversized block of irrelevant properties.

Validation should be part of implementation because small syntax or required-field errors can make markup unusable for intended search features. Development teams should test templates rather than only individual URLs because one template mistake can affect thousands of pages. Warnings should be interpreted according to whether optional information is genuinely available. Do not invent ratings, prices, reviews, or other properties just to make a validation tool look cleaner. Structured data must remain truthful. Search optimization should never require publishing information users cannot verify on the page.

Structured data also needs maintenance. Product availability changes, prices update, organizations rebrand, and template fields evolve. Markup that was correct during launch can become inaccurate when frontend content changes but backend schema rules remain untouched. Include structured data checks during major website releases and template redesigns. Large sites can monitor error trends to detect implementation problems quickly. Keeping markup synchronized with visible content reduces the chance of losing eligibility for enhanced results.

Structured data is the final item in this checklist because it should enhance a technically healthy website rather than distract from larger problems. Fix blocked pages, duplicate URLs, broken redirects, poor performance, and weak architecture before spending excessive time on optional markup. Schema cannot rescue pages that search engines cannot crawl or users do not find valuable. Once the foundation is strong, structured data can provide clearer machine-readable context around important content. Technical SEO is most effective when priorities are solved in the correct order instead of chasing advanced features before basic accessibility works.

Frequently Asked Questions

What is a technical SEO checklist?

A technical SEO checklist is a structured set of checks used to make sure search engines can crawl, render, understand, and index a website correctly. It commonly covers indexation, canonicals, redirects, sitemaps, robots.txt, page performance, mobile usability, internal linking, and structured data.

What technical SEO issues should I fix first?

Prioritize problems that prevent important pages from being crawled or indexed, such as accidental noindex tags, robots.txt blocks, broken canonicals, server errors, and failed redirects. After those critical issues, focus on architecture, performance, mobile usability, and enhancements such as structured data.

How often should I perform a technical SEO audit?

The right frequency depends on how often the website changes. Large ecommerce sites and frequently updated platforms may need continuous monitoring, while smaller websites can often perform deeper audits periodically and after major redesigns, migrations, or CMS changes.

Can technical SEO improve rankings by itself?

Technical SEO can improve rankings when technical problems are preventing strong pages from being crawled, indexed, consolidated, or experienced properly. However, a technically perfect website still needs relevant content, authority, and strong search intent alignment to compete consistently.

What is the difference between technical SEO and on-page SEO?

Technical SEO focuses mainly on crawling, indexation, architecture, rendering, performance, canonicals, redirects, and other infrastructure issues. On-page SEO focuses more directly on page content, titles, headings, keyword relevance, intent, and how individual pages communicate their subject.