Companies often start SEO by writing articles. But if a search engine cannot reliably crawl, render and index the site, new content performs below its potential. This article is for marketing leads, product owners and developers. For each item we cover how to recognise the problem, how to fix it and which misconception tends to surround it. We draw on Google Search Central and web.dev documentation and on our experience running our own content portals in the Slovak, Czech and Swiss markets. The order follows dependencies: without measurement you cannot see the effect of changes.

1. Measurement and a baseline

How to recognise it: you cannot say how many enquiries or orders came from organic search last month. Google Analytics 4 records visits, but key events (GA4’s current name for what used to be conversions) are either not set up or counted twice.

How to fix it: record a baseline before the first change, using the Performance report in Search Console (clicks, impressions, average position) and, in GA4, key events tied to a business outcome. Linking Search Console to GA4 adds query and landing-page reports, but the data arrives roughly 48 hours late, goes back at most 16 months and joins GA4 data only on landing page, device and country. Check orders against server-side data or your CRM too, because in-browser measurement misses visitors who decline or block it. Log every technical change with its date.

Common misconception: steering by the position of a single keyword. Average position is the average of the site’s topmost position, not the rank a particular person sees, and since 2025 Search Console also counts AI Mode in its totals. Follow trends in clicks and key events.

2. Indexing

How to recognise it: the Page indexing report in Search Console shows which URLs are indexed and why the others are not. Google itself says canonical pages should be indexed, not every URL, and that ‘not indexed’ is not necessarily bad. Read the reasons in groups:

  • ‘Page with redirect’ and ‘Alternate page with proper canonical tag’: usually fine.
  • ‘Duplicate, Google chose different canonical than user’: Google disagrees with your canonical, so look for conflicting signals (item 3).
  • ‘Crawled – currently not indexed’: crawled but not added. Resubmitting is not needed. Check whether the page is thin or a near-duplicate.
  • ‘Discovered – currently not indexed’: Google knows the URL but has postponed crawling it. Large numbers of these can point to a crawl capacity problem.
  • ‘Soft 404’ and noindex: check whether it is intentional. A ‘not found’ page should return a 404 status, not 200.

How to fix it: check whether pages meant to generate revenue are among the non-indexed ones. The URL Inspection tool shows the indexed version, both the canonical you declared and the one Google selected, and offers a live test. Requesting indexing does not guarantee inclusion and has a daily limit.

Common misconception: blocking unwanted pages in robots.txt and expecting them to drop out of the index. Robots.txt prevents crawling, not indexing, so a blocked URL can still be indexed without its content. To keep a page out, use noindex on a page Google is allowed to crawl.

3. Duplicates, canonicalisation and crawl capacity

How to recognise it: the same page is served at several addresses, for example with and without a trailing slash, with tracking, sorting and filter parameters, or over both HTTP and HTTPS. In the indexing report this shows up as ‘Duplicate…’ reasons and in crawl stats as thousands of parameter URLs.

How to fix it: through canonicalisation Google consolidates the signals of duplicate URLs, such as links, into one preferred URL. Redirects and rel=canonical are strong signals, sitemap inclusion a weak one. Google nevertheless describes a canonical as a hint, not a rule, and may pick a different one. So everything should point the same way: internal links to the canonical URL, the same address in the canonical tag and the sitemap, absolute URLs, HTTPS only, and the canonical in the HTML itself rather than rewritten by JavaScript.

Google covers crawl budget in a guide for large sites: roughly a million or more pages changing weekly, or 10,000 or more changing daily. If your new pages are crawled on the day they are published, Google says you do not need that guide. For faceted filters it recommends returning 404 for combinations with no results, keeping parameter order consistent and blocking unneeded filters in robots.txt.

Common misconception: ‘every duplicate splits a page’s authority’. Google states no such rule and instead consolidates signals. Another is saving crawl capacity with noindex: Google still fetches such a page and only then drops it. Canonicalisation within a site should rest on rel=canonical and redirects, not on noindex or robots.txt.

4. Discoverability: links, sitemaps and JavaScript

How to recognise it: a page no ordinary link points to is discovered slowly and with difficulty. Typical cases are products reachable only through on-site search (Googlebot generally does not submit search forms), navigation built from elements without an href attribute, content that loads only after a click or scroll (the crawler does not interact with the page) and applications rendered entirely in the browser. How to fix it:

  • Links as an HTML a element with an href attribute pointing to a real address.
  • Categories link directly to products, and important pages are linked from the home page and navigation. Google considers how many links it must follow to reach a page when estimating its importance, but its documentation sets no fixed ‘three-click rule’.
  • A sitemap with canonical, absolute URLs (at most 50,000 URLs and 50 MB uncompressed per file) and a lastmod that changes only on significant changes. Google ignores priority and changefreq. Neither a sitemap nor a product feed guarantees indexing. Both supplement links rather than replace them.
  • JavaScript: Google crawls, renders and indexes a page, and rendering may wait in a queue. It still recommends server-side rendering or pre-rendering. Do not rely on JavaScript to remove an initial noindex: Google may skip rendering. JavaScript can add a canonical, but Google recommends declaring a consistent canonical in the source HTML and avoiding conflicting values.

The live test in URL Inspection shows the HTML Google received and a screenshot. A common misconception is ‘Google cannot handle JavaScript’, and equally ‘it handles everything’. It can render it, but it will not find links without href or content hidden behind an interaction.

5. Language and country versions (hreflang)

How to recognise it: Search Console shows visits from one country landing on the version meant for another, or Google selects a different language version as canonical. With closely related languages such as Slovak and Czech this is more noticeable, because both versions can look relevant for the same query. We use hreflang between markets on our own portals too. Common mistakes:

  • Missing return links: if two pages do not point to each other, Google ignores their annotations. Each version lists itself and all the others.
  • Wrong codes: language per ISO 639-1, optionally a region per ISO 3166-1 alpha-2. Czech is ‘cs’, not ‘cz’, which is the country code. A country code alone is not enough, and German for Switzerland is ‘de-CH’.
  • A canonical pointing to another language version. Translated pages are not duplicates, so the canonical should point to a page in the same language.
  • Misunderstanding x-default: it is an optional hreflang value that marks the version for users whom no listed language or region matches, typically a language selector page. Its absence is not an error in itself.
  • Automatic redirection by IP address or browser language. Googlebot mostly crawls from the USA without an Accept-Language header, so it may not see some versions. Links to the other versions work better.

Common misconception: hreflang sets a page’s language or improves its ranking. Google detects language from the content, and hreflang tells it which of the equivalent versions to show to whom. Declaring it in HTML, an HTTP header or the sitemap is equivalent, and one method is enough.

6. Core Web Vitals and the mobile version

There are currently three metrics: LCP (rendering of the largest element) within 2.5 s, INP (responsiveness to interaction) within 200 ms and CLS (layout shifts) at most 0.1. INP replaced FID on 12 March 2024. The ‘needs improvement’ band runs up to 4 s, 500 ms and 0.25. The 75th percentile of page loads is assessed, separately for mobile and desktop.

How to recognise it: what counts is CrUX field data, visible in PageSpeed Insights and Search Console. It comes from Chrome users who have opted in to sharing usage statistics (excluding Chrome on iOS and other browsers), and only from pages with enough traffic. Lighthouse provides lab data from a simulated load and cannot measure INP, so Total Blocking Time serves as the proxy.

How to fix it: check first for a large hero image without set dimensions or load priority, third-party scripts blocking the main thread, and late-injected elements that push content around. Google indexes the mobile version of a site, so it must carry the same content as the desktop one. Content may be tucked into tabs, but it must not be left out. On our own portals we track Core Web Vitals on real mobile devices, not only in the lab.

Common misconception: a Lighthouse score of 100 means the job is done, or good Core Web Vitals will push a page to the top. Google says they do not guarantee a top ranking and that it shows the most relevant content even when the page experience is sub-par.

7. Structured data

Structured data helps a search engine understand content and, for supported types, can make a rich result available. The list of types changes: Google has not shown HowTo results since September 2023, restricted FAQ results in 2023 to well-known government and health websites, and has not shown them at all since 7 May 2026. It retired further less-used types in 2025 and 2026.

How to recognise and fix it: the rich result reports in Search Console and the Rich Results Test show errors for supported types. Mark up only content users can see on the page, and only types that belong to it (Article, Product, Organization, BreadcrumbList). Our own portals carry structured data on every page, and it has proved useful to generate it from the same data as the visible text so the two cannot drift apart. Google says unused FAQ markup does not need to be removed in bulk.

Common misconception: structured data raises rankings or guarantees more clicks. It does not raise rankings by itself, and neither a rich result nor a higher click-through rate is guaranteed, even with flawless markup. Misleading markup risks a manual action, which removes eligibility for rich results.

Order of work and when not to bother

Only once a site is measurable, indexable and discoverable does it make sense to write more content. A small, well-linked site need not worry about crawl budget and, according to Google, up to around 500 pages may not even need a sitemap. Fixes are not one-off: every release can add parameters, redirects or a third-party script. On our own portals the checks that can be automated (dead links, HTML validation, an SEO audit) therefore run regularly and a person deals only with the findings. We recommend including at least canonical, status-code and hreflang checks in the review before every deployment.