SEO Checklist

Google Search Console (GSC) is the primary tool for understanding how Google sees your site. It reports indexing issues, search performance data, Core Web Vitals, and security problems. Everything else on this checklist depends on having GSC set up.

What to do:

Verify ownership of your domain in Google Search Console. Submit your XML sitemap once verified. If you are migrating domains, remember to move the verification tag to the new site.

GA4 tracks how visitors find and interact with your site across sessions and devices. It provides the data needed to evaluate whether marketing efforts translate into actual business outcomes, and forms the foundation for any data-informed marketing decisions.

What to do:

Install GA4 via your platform's native integration or Google Tag Manager. Confirm the data stream is receiving data. Check that consent mode is configured correctly for your region's privacy requirements.

Bing powers search results for Microsoft Edge, DuckDuckGo, Yahoo, and Copilot AI answers. Bing Webmaster Tools also supports IndexNow, a protocol that notifies search engines about content changes in real time rather than waiting for the next crawl.

What to do:

Import your site from Google Search Console into Bing Webmaster Tools (saves re-verification). Enable IndexNow if your platform supports it. Submit your sitemap.

IndexNow is an open protocol that lets you notify participating search engines (Bing, Yandex, Naver, Seznam, Yep) the moment content is created, updated, or deleted. Instead of waiting for crawlers to discover changes, your site pushes the update. Submitting to one participating engine automatically shares with all others. Google does not currently support IndexNow, but the protocol covers the other major engines and AI answer surfaces that pull from Bing.

What to do:

Check if you already have IndexNow: several CMS platforms include it natively with no setup needed (Wix, Duda, WordPress.com). If you use Cloudflare as your CDN, enable Crawler Hints in the dashboard (one toggle). For WordPress (.org), install the official IndexNow plugin by Microsoft, or use Yoast SEO Premium, RankMath, or AIOSEO which all include IndexNow support. Shopify users can install InstaIndex. For platforms without native support, the manual setup involves generating an API key, hosting a key file at your domain root, and submitting URLs via the IndexNow API. Verify submissions are working in Bing Webmaster Tools.

Title tags appear as the clickable link in search results and are the single most influential on-page SEO element. A unique, descriptive title on every page helps search engines understand the content and gives searchers a reason to click.

What to do:

Write a unique, descriptive title for every page. Keep them under 60 characters to avoid truncation. Include relevant keywords naturally. Google may rewrite titles it considers unhelpful, so write for the reader first.

Search engines often display the meta description as the snippet below the title in results. While not a direct ranking factor, a well-written description improves click-through rate because it sets expectations for the reader.

What to do:

Write a concise summary (150-160 characters) for every important page. Missing descriptions leave Google to auto-generate a snippet from page content, which may not represent the page well. Prioritise high-traffic pages first.

Canonical tags tell search engines which URL is the preferred version of a page. They consolidate ranking signals that might otherwise be split across duplicate URLs from query parameters, www/non-www variants, trailing slashes, and product collection URLs.

What to do:

Confirm each page has a self-referencing canonical tag pointing to the clean, preferred URL. Check for common conflicts: non-www vs www, trailing slash vs no trailing slash, HTTP vs HTTPS.

Your site should resolve to a single canonical domain format. If both www.example.com and example.com serve content, search engines may treat them as separate sites, splitting ranking signals and causing duplicate content issues.

What to do:

Choose one format (with or without www) and redirect all other variants with 301 redirects. Apply the same logic to trailing slashes: pick one convention and redirect the other. Confirm canonical tags match your chosen format.

An XML sitemap tells search engines which pages exist on your site and when they were last updated. Most platforms generate one automatically at /sitemap.xml.

What to do:

Submit your sitemap URL to Google Search Console and Bing Webmaster Tools. Check that the sitemap only includes pages you want indexed (not admin pages, thank-you pages, or filtered product views). Resubmit after major site changes or migrations.

Robots.txt controls which parts of your site search engine crawlers can access. A misconfigured robots.txt can accidentally block important pages from being crawled. It does not prevent indexing on its own; use noindex tags for that.

What to do:

Check your robots.txt at yourdomain.com/robots.txt. Confirm it references your sitemap location and does not disallow important page paths. If you have multiple international sitemaps, list each one.

When you remove a page or change its URL, a 301 redirect forwards visitors and ranking signals from the old URL to the new one. This preserves any authority the original page had earned and keeps bookmarks and external links working.

What to do:

Set up 301 redirects from old URLs to their closest relevant replacement. Check Google Search Console's Pages report for 404 errors that may need redirects. After a site migration, redirect every significant old URL to its new equivalent.

A redirect chain occurs when URL A redirects to B, which redirects to C (or longer). Each hop slows the user experience and dilutes ranking signals. Chains often accumulate over multiple site redesigns or platform migrations.

What to do:

Update redirects so each old URL points directly to the final destination, not through intermediate stops. Update internal links to point to the final URL rather than relying on the redirect. Crawl tools like Screaming Frog surface chains easily.

Keeping links healthy across your site improves the experience for visitors and helps search engines crawl efficiently. Regularly checking for broken internal and external links catches issues before they accumulate.

What to do:

Run a crawl periodically (Google Search Console, Screaming Frog, or Ahrefs Site Audit) to identify broken links. Fix internal links by updating the href or adding a redirect. For external links, replace with a working URL or remove the link.

Schema.org markup (usually JSON-LD) helps search engines understand your content and can trigger rich results like review stars, FAQ accordions, product prices, and event details in search results.

What to do:

Add structured data to your most important page types: product pages, FAQ pages, articles, local business pages, and events. Focus on schema types that your content genuinely supports.

Alt text helps search engines understand images for image search rankings, provides context for AI surfaces processing your content, and is essential for screen reader users. It appears in place of the image if it fails to load.

What to do:

Add concise, specific alt text to every non-decorative image. "Red running shoes on a trail" is useful; "image" or "photo" is not. For product images, include the product name and key attributes. Leave alt empty (alt="") for purely decorative images.

Internal links help search engines discover your pages, understand how they relate, and distribute ranking signals across your site. Orphaned pages (with no internal links pointing to them) are difficult for search engines to find and rank.

What to do:

Link related pages to each other using descriptive anchor text. Prioritise linking to your most important pages from high-traffic pages like the homepage and popular blog posts. Avoid generic anchor text like "click here."

When visitors land on a page that does not exist, a helpful 404 page helps them find what they were looking for instead of leaving the site entirely.

What to do:

Create a custom 404 page with navigation, a search bar, and links to popular or relevant pages. Most platforms let you customise the 404 template in theme settings.

Breadcrumbs show users where they are in your site hierarchy (e.g. Home > Shoes > Running Shoes) and give search engines a clear picture of your site structure. Google can display breadcrumbs in search results instead of the raw URL, which improves readability and click-through rate.

What to do:

Add visible breadcrumb navigation to product, category, and content pages. Implement BreadcrumbList schema markup (JSON-LD) alongside the visible breadcrumbs so Google can use them in search results. Most modern themes include breadcrumbs, but check that the structured data is present using Google's Rich Results Test.

Search engines and screen readers understand your pages better when the HTML uses meaningful elements for each area: a main content region, clearly defined navigation, headers, and footers. Most modern themes handle this correctly, but custom sections or page builder layouts sometimes use generic markup that loses this structure.

What to do:

If you are using a standard theme from your platform's marketplace, this is likely already in place. If you have custom-built sections or use a page builder extensively, ask your developer to verify that the key areas of each page are marked up with appropriate HTML5 elements.

Search engines can execute JavaScript to render pages, but content that appears in the initial HTML response is discovered and indexed more reliably. Client-side-only rendering (where content loads after JavaScript executes) can delay indexing and sometimes causes content to be missed entirely.

What to do:

Check by viewing the page source in your browser (right-click > View Page Source) on a few key pages. If the main text and headings are visible in the raw HTML, your content is accessible to search engines.

Google Business Profile (formerly Google My Business) controls how your business appears in Google Maps and local search results. A complete, verified profile with accurate hours, address, phone number, photos, and business categories is the foundation of local SEO.

What to do:

Claim and verify your listing. Fill in every relevant field: business name, category, address, phone, hours, website URL, description, and attributes. Add high-quality photos of your premises, products, and team. Keep hours up to date, especially for holidays and seasonal changes. Respond to reviews.

Search engines cross-reference your business name, address, and phone number across your website, Google Business Profile, directories, and social profiles. Inconsistencies (abbreviations, old addresses, different phone formats) can weaken local ranking signals.

What to do:

Use the exact same business name, address format, and phone number everywhere: your website footer, contact page, Google Business Profile, social profiles, and directory listings. Include LocalBusiness schema markup on your site with matching NAP details.

Google Merchant Centre connects your product catalogue to Google Shopping, free product listings, and Performance Max campaigns. For e-commerce businesses, it is the bridge between your product feed and Google's shopping surfaces.

What to do:

Create a Merchant Centre account and connect it to your website. Most platforms offer a native integration that syncs your product catalogue automatically. Confirm your products are appearing correctly, prices are up to date, and product data passes validation without errors.

LocalBusiness schema markup gives search engines structured information about your physical business: address, opening hours, phone number, price range, and service area. It supports rich results in local search and helps AI surfaces provide accurate business information.

What to do:

Add LocalBusiness (or a more specific type like Restaurant, Store, or MedicalBusiness) schema to your homepage or contact page. Include: name, address, telephone, openingHours, priceRange, and geo coordinates. Validate with Google's Rich Results Test.

Multimarket sites need a consistent URL pattern that search engines can parse. The three common approaches: subdirectories (example.com/uk/, example.com/de/), subdomains (uk.example.com), or country-code top-level domains (example.co.uk). Each has trade-offs for SEO authority consolidation, hosting complexity, and analytics setup.

What to do:

Subdirectories are the simplest option for most small and mid-sized businesses because all markets share the same domain authority and hosting. Subdomains and ccTLDs can make sense for larger operations with dedicated teams per market. Whichever pattern you choose, apply it consistently and ensure each market has its own sitemap, canonical tags, and hreflang annotations.

Hreflang tags tell search engines which version of a page to show to users in each language and region. Every variant must reference all other variants (including itself), and country codes must be in the correct format (en-GB, not en-gb). Misconfigured hreflang is one of the most common technical SEO errors on multilingual sites.

What to do:

Implement hreflang annotations via HTML tags, HTTP headers, or XML sitemaps (using multiple methods adds redundancy). Include an x-default tag pointing to your fallback page. The Addy Hreflang Sitemap Generator validates bidirectional references automatically.

Each market or language version of your site benefits from its own XML sitemap. This gives search engines a clear inventory of which pages belong to each locale, helps with targeted indexing, and makes it easier to monitor coverage in Google Search Console by adding each sitemap as a separate property.

What to do:

Generate per-locale sitemaps (e.g. /uk/sitemap.xml, /de/sitemap.xml) with hreflang annotations and per-locale output. Reference all sitemaps in your robots.txt. Submit each to the relevant Google Search Console property.

If your international markets use subdomains or separate domains, a single GA4 property may not track users correctly as they navigate between them. Cross-domain tracking ensures sessions are not broken when a user moves from example.co.uk to example.de, and that attribution data flows accurately.

What to do:

In GA4, configure cross-domain measurement in Admin > Data Streams > Configure tag settings > Configure your domains. List all domains and subdomains used across markets. Confirm UTM parameters pass correctly between domains. For subdirectory-based sites on a single domain, this is not needed.

Direct translation of page content often misses local search intent, idioms, and product naming conventions. Users in different markets search differently, and search engines favour content that matches local language patterns. A page translated word-for-word may technically rank but underperform content written for the local audience.

What to do:

Localise (not just translate) title tags, meta descriptions, product descriptions, and key landing page content for each market. Research local keyword patterns in Google Search Console and Keyword Planner per market. Adapt currency, measurements, date formats, and seasonal references.

LCP measures how quickly the main content of your page loads. It is the Core Web Vital most directly tied to perceived speed. Common causes of slow LCP: unoptimised hero images, slow server response, render-blocking CSS/JS, and web fonts that delay text rendering.

What to do:

Check your LCP in Google Search Console's Core Web Vitals report, PageSpeed Insights, or the CrUX Vis dashboard (cruxvis.withgoogle.com). For ongoing monitoring across your whole site, set up the CrUX Dashboard in Looker Studio (g.co/chromeuxdash). Optimise hero images (compress, serve in WebP/AVIF, set explicit dimensions). Avoid lazy-loading the hero image. Preload critical fonts.

INP measures how quickly your page responds to user interactions like clicks, taps, and key presses. Slow INP is usually caused by heavy JavaScript execution, large DOM trees, or third-party scripts (analytics, chat widgets, ad tags) blocking the main thread.

What to do:

Review INP data in Google Search Console, PageSpeed Insights, or CrUX Vis (cruxvis.withgoogle.com) which visualises real-user Core Web Vitals over time. Identify heavy third-party scripts and consider loading them asynchronously or removing unused ones. Reduce DOM complexity where possible.

CLS measures how much visible content shifts unexpectedly during page load. The most common causes: images and embeds without explicit width and height attributes, late-loading fonts that change text size, and dynamically injected content (ads, cookie banners, promotional bars) that pushes elements down.

What to do:

Always set width and height attributes on images and video embeds. Use font-display: swap to prevent font-related layout shifts. Reserve space for late-loading content like ads or cookie banners with fixed-height containers.

Optimised images are one of the simplest ways to improve page load speed. Serving correctly sized images in modern formats reduces bandwidth and speeds up rendering, especially on mobile.

What to do:

Serve images in modern formats (WebP or AVIF where supported). Compress them. Always set width and height attributes to prevent layout shifts. Use responsive images (srcset) so mobile devices download smaller files. Lazy-load images below the fold, but not the hero image.

Web fonts that load slowly cause invisible text (FOIT) or layout shifts when the font file finally arrives and text reflows. Multiple font families and weights compound the problem.

What to do:

Use font-display: swap or font-display: optional to prevent invisible text while fonts load. Limit the number of font families and weights. Preload the primary font file if LCP depends on rendered text. Consider system fonts for body text if performance is a priority.

CSS and JavaScript files in the <head> block page rendering until they finish downloading and executing. Third-party scripts (analytics, marketing tags, chat widgets) are a common culprit. On framework-driven sites, CSS chunking is mostly handled by the framework, so the practical levers are limiting third-party scripts and turning on the framework's critical-CSS option.

What to do:

Defer non-critical JavaScript with `defer` or `async`. On modern frameworks (Next.js, Astro, Remix), inlining critical CSS is exposed through a single config flag, such as `experimental.optimizeCss` on Next.js or `inlineStylesheets` on Astro. Audit with PageSpeed Insights and look for the "Eliminate render-blocking resources" recommendation. Treat each third-party script in the `<head>` as a candidate for moving lower in the document or loading conditionally.

PageSpeed Insights flags "Legacy JavaScript" when a site ships polyfills (small shims that backfill modern features) for browsers that already support those features natively. The unused bundle commonly adds 15 to 25 KB, delaying first paint without benefiting current visitors.

What to do:

Set an explicit browser target list in the build configuration. On Next.js, Vite, and Astro projects this usually means adding a `browserslist` field to `package.json`. Chrome and Edge 118+, Firefox 119+, and Safari 17+ cover the Baseline Widely Available set, which is enough for most public-facing sites. The bundler then drops the polyfills on the next build. Managed platforms (Shopify themes, Wix, Squarespace) handle this through platform updates and aren't user-configurable.

When a page loads resources from a different origin (a font CDN, payment script, analytics endpoint), the browser pays the cost of a DNS lookup, TCP handshake, and TLS negotiation before the first byte arrives. A preconnect hint in the `<head>` tells the browser to start that work earlier, in parallel with parsing the rest of the document.

What to do:

Add a preconnect hint for the first cross-origin request that affects LCP. Common candidates are a font provider, payment SDK, or analytics endpoint loaded above the fold. Limit the list to four origins. Preconnects that go unused waste a connection slot, so review them whenever a third-party script comes off the page.

Low-contrast text is hard to read for users with visual impairments and in bright lighting conditions. WCAG AA requires a contrast ratio of at least 4.5:1 for normal body text and 3:1 for large text (18px+ or 14px+ bold).

What to do:

Check your colour combinations with the WebAIM Contrast Checker or your browser's built-in accessibility tools. Pay special attention to light grey text on white backgrounds, which is a common issue in modern designs.

Headings create the document outline that screen readers use for navigation and that search engines use to understand content structure. Skipping levels (jumping from h1 to h4) or using headings for visual styling rather than structure breaks this outline.

What to do:

Use a single h1 per page that describes the main topic. Use h2 for major sections, h3 for subsections. Do not skip levels. Do not use heading tags for visual styling; use CSS instead.

Every form input should have a visible label associated via the HTML <label> element. Placeholder text alone is not sufficient because it disappears when the user starts typing. Properly labelled forms also work better with autofill and assistive technology.

What to do:

Check that every text field, dropdown, checkbox, and radio button has a visible label. If your theme uses placeholder-only forms, add visible labels above or beside each input.

Users who rely on keyboards or assistive devices need to be able to tab through all links, buttons, form fields, and interactive elements. Custom interactive elements (built with div or span instead of native button or a tags) often break this.

What to do:

Press Tab through your site without using a mouse. Confirm all interactive elements receive focus in a logical order. Check that custom elements include the appropriate role attribute (role="button") and tabindex if they are not native HTML elements.

Small or closely spaced buttons and links make it difficult for mobile users to tap accurately. Google's mobile usability report flags tap targets smaller than 48x48 CSS pixels.

What to do:

Review key interactive elements on mobile. Increase the size of buttons, links, and form fields that are below 48x48 pixels. Add padding between closely spaced tap targets so users do not accidentally hit the wrong one.

When a user tabs through interactive elements, each focused element should have a visible outline or highlight. Removing the default browser focus ring (outline: none) without providing a custom replacement breaks keyboard navigation.

What to do:

If your theme removes default focus rings for aesthetic reasons, add a custom focus style. A 2px solid outline in a contrasting colour is a simple solution that satisfies WCAG requirements.

A hidden link at the very top of each page that becomes visible on keyboard focus and jumps the user past the navigation to the main content. It lets keyboard users reach the content directly instead of tabbing through every navigation link on every page.

What to do:

Check by loading your site and pressing Tab once. If a "Skip to content" link does not appear, add one. Most modern themes include this by default.

HTTPS is a confirmed Google ranking signal, a requirement for many browser features, and a baseline expectation for any site that handles user data. It ensures data transferred between the visitor and your server is encrypted.

What to do:

Confirm your site loads over HTTPS by checking for the padlock icon in the address bar. If you recently moved to HTTPS, ensure all internal links and resources use HTTPS URLs to avoid mixed content warnings.

A valid SSL certificate keeps HTTPS working and the padlock icon visible in browsers. Let's Encrypt certificates (used by most managed hosts) renew automatically every 90 days, so the main thing to confirm is that auto-renewal is enabled.

What to do:

Check your certificate expiry date and confirm auto-renewal is enabled. Self-hosted WordPress sites should confirm their host provides auto-renewal. Set a calendar reminder to check quarterly.

Mixed content occurs when an HTTPS page loads resources (images, scripts, stylesheets) over HTTP. Browsers flag or block these requests, which can break page functionality and display security warnings.

What to do:

Open your browser's developer console (F12) and look for mixed content warnings. Update any HTTP resource URLs to HTTPS. Common culprits: hardcoded image URLs, embedded content from older services, and legacy tracking scripts.

A Content-Security-Policy (CSP) header restricts which sources can load scripts, styles, images, and other resources on your pages. It helps prevent cross-site scripting (XSS) attacks.

What to do:

For most small business sites, this is a nice-to-have rather than urgent. If you want to implement it, start with a report-only policy to monitor violations before enforcing restrictions. Check your current headers at securityheaders.com.

The X-Frame-Options header (or the newer Content-Security-Policy frame-ancestors directive) prevents your site from being embedded in iframes on other domains. This protects against clickjacking attacks.

What to do:

Check your headers at securityheaders.com. If the header is missing and your host does not set it by default, adding it is a low-effort improvement. Most sites should use SAMEORIGIN or DENY.

Google's page experience signals include whether content is immediately accessible on page load, especially on mobile. Full-screen email signup popups that appear before the user has scrolled are the most common issue flagged here.

What to do:

Acceptable: age verification (legally required), login dialogues for paywalled content, and small banners using a reasonable amount of screen space. Avoid full-page overlays that trigger on page load. If you use a popup, delay it until the user has engaged with the page.

Content should be readable without zooming, tap targets should be large enough, and horizontal scrolling should not be required. Google uses the mobile version of your page as the primary version for indexing and ranking.

What to do:

Check the Mobile Usability report in Google Search Console for page-level issues. Use responsive design (single URL, CSS adapts to screen size). Test on actual mobile devices, not just browser resize.

Google Search Console's Security Issues report flags malware, hacked content, deceptive pages, and other threats. These trigger browser warnings that block visitors and cause search result demotion.

What to do:

Check the Security Issues report in Google Search Console periodically. Review after installing new plugins, themes, or third-party code, as compromised third-party code is a common vector.

If your site displays advertising, the ad density should comply with the Coalition for Better Ads standards. Google Chrome can block ads on sites that repeatedly violate these standards.

What to do:

Avoid: full-page ads before content loads, sticky ads taking up more than 30% of the screen, and auto-playing video ads with sound. If you are not running ads, this does not apply.

Google PageSpeed Insights reports your Core Web Vitals from real users (field data) alongside Lighthouse lab simulations. Running it periodically on key pages catches performance regressions before they affect rankings. The field data reflects what Google uses for ranking; lab scores can vary between runs, so treat them as directional.

What to do:

Test your homepage and top landing pages quarterly or after major site changes. Focus on the field data section first. For ongoing monitoring, CrUX Vis visualises real-user metrics over time, and the CrUX Dashboard in Looker Studio provides monthly trends.