Free tool
The relaunch checklist that cites its sources
The 56 items without which, by our knowledge base’s developer kit, a site is not ready to launch. Each one says why it matters, how to build it, how to test it and which Google page it rests on. Filtered to your situation, free, no sign-up.
By Ibram & Dawwa GmbHUpdated 13 October 2026Sources checked 13 October 2026Knowledge base v2.13.0
How to use the list
- Pick your situation: a relaunch, a domain change, a platform or framework change, or a multilingual site or new language. The list then shows the items that matter for it, grouped into before go-live, launch day and the weeks after. If several apply, pick “All situations”.
- Open an item to see why it matters, how to build it, how to test it and the sources it rests on: Google’s documentation and what was said at Search Central Live.
- Tick what is done: a must item once it is in place, an avoid item once you have checked that the site does not do it.
- Export the list to CSV for Jira, Linear or GitHub, with the test column as the acceptance criterion, or print it for the release review.
Nothing is scanned: the page never asks for a URL and never fetches your site. Your ticks stay in your browser.
Every one of the 56 items is backed by Google’s documentation, and many were discussed further at Search Central Live 2026. The list reflects knowledge base v2.13.0, with data through 2 October 2026.
opens in a new tab
Your situation
0 of 56 done
56 of 56 items shown
Nothing is scanned: this page never fetches your site.
Your ticks are kept only in your browser’s local storage. They are never sent to us.
Before go-live
Let verified Google crawlers through firewalls, CDNs and bot protection
Why · How · How to test · Sources
- Why
- Google cannot tell that a firewall or bot rule is blocking it; it only sees failing requests. Timeouts, connection resets and DNS errors are treated like 5xx errors: crawling slows down at once, and indexed URLs that stay unreachable drop out of the index within days.
- How
- Allowlist Google's crawlers in WAF, CDN and bot-management rules by the IP ranges Google publishes (common-crawlers.json, special-crawlers.json) or by reverse DNS to crawl-*.googlebot.com or geo-crawl-*.geo.googlebot.com, never by user-agent string alone. Do not rate-limit or challenge verified Googlebot with CAPTCHAs or JavaScript puzzles, make sure DNS resolves reliably for every host, and review the rules after every CDN or security-vendor change.
- How to test
- In Search Console's Crawl stats report, host status shows no robots.txt fetch, DNS resolution or server connectivity failures. The URL Inspection live test succeeds for one URL per template, and WAF/CDN logs show no 403, 429 or challenge responses to IPs that verify as Googlebot.
- Sources
In Google's documentation
- Crawling December: CDNs and crawling
- Debug network and DNS errors for Google's crawlers
- Verify requests from Google crawlers and fetchers
- Overview of Google crawlers and fetchers
Said at Search Central Live
- ibramdawwa.de: Pass
- No CDN or bot protection sits in the path: seven user agents, Googlebot among them, got identical 200 responses and 16 parallel requests all returned 200 (Crawl stats in Search Console not read for this check).
Never serve bot challenges or error pages to crawlers with a 200 status
Why · How · How to test · Sources
- Why
- Google finds a bot-challenge page very hard to recognise as an error. Served with 200 on many URLs, the identical page can make Google cluster those URLs as duplicates and drop them, and recovery is slow; a 200 error page is also a soft 404.
- How
- If a crawler must get a challenge or block page, send it with 503 (as Google's CDN guidance recommends for bot-verification interstitials) or with 429 for rate limiting, never with 200. Most CDN and bot-management products let you set this status code; better still, do not challenge verified Google crawlers at all.
- How to test
- Request a few URLs with a Googlebot user agent from an unverified IP: any challenge comes back as 503 or 429, never 200. The Page indexing report shows no sudden rise of "Duplicate" or "Soft 404" on unrelated URLs.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- No challenge or interstitial is served: crawlers and browsers get the same page, and unknown URLs answer 404, not 200.
Keep robots.txt reachable on every host: 200 with rules, or 404 if there are none
Why · How · How to test · Sources
- Why
- If robots.txt answers with a 5xx error, Google stops crawling the site for the first 12 hours and then relies on a cached copy for up to 30 days. The rules apply per host and only at the root, so the file on www does nothing for an API or CDN host name.
- How
- Serve /robots.txt at the root of every host name that serves pages or rendering resources (www, the bare domain, API, static, CDN and country hosts): 200 with the rules, or 404 if the host has none. Exclude robots.txt from maintenance modes, WAF challenges and authentication.
- How to test
curl -I https://<each-host>/robots.txtreturns 200 or 404, never 5xx, 401/403 or a redirect to a login page. Search Console's robots.txt report (Settings) shows each host's file as fetched.- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- robots.txt answers 200 on https://ibramdawwa.de, and the www and http variants redirect to it in one hop.
Rely only on the fields Google supports (user-agent, allow, disallow, sitemap) and keep robots.txt under 500 KiB
Why · How · How to test · Sources
- Why
- Google supports only user-agent, allow, disallow and sitemap and ignores other lines such as crawl-delay, so they save no crawl budget with Google. It reads only the first 500 KiB of the file and generally caches it for up to 24 hours, so a change can take a day to apply.
- How
- Cover URL patterns with the * and $ wildcards instead of listing URLs; the longest matching rule wins, and when rules conflict Google uses the least restrictive one. Spell field names exactly, add the Sitemap line with an absolute URL, and plan changes a day ahead or request a recrawl in the robots.txt report.
- How to test
- Check fetch status, warnings and errors in Search Console's robots.txt report and test the file with an RFC 9309 parser such as Google's open-source robots.txt library (github.com/google/robotstxt). The file is well under 500 KiB, and important URLs (home page with tracking parameters, JS bundles, API endpoints, filter URLs) are spot-checked against the rules.
- Sources
In Google's documentation
- How Google interprets the robots.txt specification
- Robots.txt report
- Update your robots.txt file
- Google's open-source robots.txt parser
Said at Search Central Live
- ibramdawwa.de: Pass
- robots.txt has four lines (User-Agent, Allow, Disallow: /api/, Sitemap), only supported fields, far below 500 KiB.
Do not put Content-Signal or other non-standard lines between user-agent lines
Why · How · How to test · Sources
- Why
- Googlebot ignores an unknown line between two user-agent lines and merges both user agents into one group, so the rules that follow apply to both. A Google slide at Search Central Live showed Bing closing the group at that line instead, so the same file blocks one crawler and not the other; managed robots.txt files from some CDNs add such lines.
- How
- Keep each group as an uninterrupted run of user-agent lines followed by its allow and disallow rules. If a CDN or plug-in adds Content-Signal or similar lines, make sure they sit after a group's rules, and review the generated file after every change to the CDN settings.
- How to test
- Fetch the live file (curl https://www.example.com/robots.txt) and check that every run of user-agent lines is uninterrupted; test it in Bing Webmaster Tools' robots.txt tester and with Google's open-source parser. The latest fetched version in the robots.txt report matches the file the team deployed.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- robots.txt has a single user-agent group and no Content-Signal or other non-standard lines.
Answer crawlers over HTTP/1.1 (HTTP/2 optional); never run a crawlable host on HTTP/3 only
Why · How · How to test · Sources
- Why
- Google's crawlers support HTTP/1.1, their default, and HTTP/2; Googlebot does not support HTTP/3 today. HTTP/2 can save server resources but gives no ranking benefit.
- How
- Make every crawlable host answer over HTTP/1.1, treat HTTP/3 as an extra for browsers, and check that CDN, firewall and load-balancer rules written for HTTP/3 (QUIC) traffic do not break HTTP/1.1 or HTTP/2 responses. To opt out of HTTP/2 crawling, return 421 to Google's HTTP/2 requests.
- How to test
- curl -I --http1.1 https://www.example.com/ returns 200, and curl -I --http2 https://www.example.com/ returns the same status, canonical, robots and caching headers (unless the site deliberately answers 421). Crawl stats shows normal response times.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- HTTP/1.1 and HTTP/2 return the same status, canonical, robots tag and caching headers for /seo.
Do not answer crawlers with 401, 402 or 403 on pages that should be in Search
Why · How · How to test · Sources
- Why
- Google does not index URLs that return a 4xx status (except 429) and removes ones already indexed. Said at Search Central Live: Google has recently seen more 403 and 402 responses to its crawlers and drops those pages from Search and its AI features.
- How
- Check that login walls, paywalls, geo-blocks and bot-management rules never return 401, 402 or 403 to verified Google crawlers on public pages; for paywalled articles use the paywalled-content markup instead of an error. Keep 401 and 403 for pages that must stay out of Search, such as account areas.
- How to test
- Crawl stats and server logs show no 401, 402 or 403 responses to verified Googlebot on indexable templates, and the URL Inspection live test returns 200 for one URL per template.
- Sources
In Google's documentation
- How HTTP status codes affect Google's crawlers
- Page indexing report
- Subscription and paywalled content markup
Said at Search Central Live
- ibramdawwa.de: Pass
- No 401, 402 or 403 for any of the seven user agents tested, and all 42 sitemap URLs answer 200.
Give a crawler its own robots.txt group only when needed, and make that group complete
Why · How · How to test · Sources
- Why
- Robots.txt groups are not additive: a crawler obeys only the most specific group that names it and ignores the * group. A Googlebot group that blocks only /dogs/ therefore leaves Googlebot free to crawl everything the * group blocks (Dave Smart's example at Search Central Live).
- How
- Put the rules every crawler shares in the * group, and add a named group (Googlebot, Storebot-Google, an AI crawler token) only when that crawler needs different rules, copying in every shared rule that should still apply. Generate the file from one template so that a change to the shared rules updates every named group.
- How to test
- For each named group, run Google's open-source robots.txt parser with that crawler's token against sample URLs covering every path the * group disallows: each result is the one intended for that crawler.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- There is no group for a single crawler: one group for all user agents is all this site needs.
Never use robots.txt to hide private paths; protect them with authentication
Why · How · How to test · Sources
- Why
- Robots.txt is not a security measure: anyone can read the paths it disallows, and it only asks well-behaved crawlers not to fetch them. A disallowed URL can still be indexed if other sites link to it, and Google points to password protection for private files.
- How
- Put admin areas, internal tools, exports and staging behind authentication or an IP allowlist, or keep them off the internet, and do not list their paths in robots.txt. To keep a public page out of Search, use noindex and leave it crawlable.
- How to test
- The live robots.txt names no admin, backup, export or internal paths, and curl -I on each private path returns 401 or 403 without credentials.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- robots.txt names only /api/, the contact form endpoint, which rejects GET requests (405); no admin or backup paths are listed.
Make every navigational link an
<a>element whosehrefholds a real URLWhy · How · How to test · Sources
- Why
- Google extracts links from
<a>elements whosehrefholds a URL, from the server HTML and again from the rendered page, and uses them to discover pages and understand the site's structure. Googlebot does not click, so a link that only works through JavaScript may never lead Google to its target. - How
- Audit every component that outputs links (navigation, breadcrumbs, pagination, filters, product tiles, footers, language selectors): each needs
<a href="/real/path">, and framework link components must render thathref. Client-side routing may intercept the click as long as thehrefstays; plain-text URLs or a sitemap alone are not enough for discovery. - How to test
- In URL Inspection (rendered HTML) and in a crawler with JavaScript off and on, every navigation item appears as
<a href="...">, and a crawl from the home page reaches all key templates. A search of the rendered HTML finds no navigation throughonclick=,javascript:,routerLinkorhref="#". - Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Every navigation item is an
<a href>with a real URL, and a crawl from the home page that follows only links reached all 42 sitemap URLs.
Do not navigate with onclick handlers, javascript: URLs, routerLink without href or # pseudo-links
Why · How · How to test · Sources
- Why
- Google's link documentation calls these patterns not recommended, and a Google slide at Search Central Live put them under "cannot extract". Either way they are not dependable for discovery, and they are common in single-page apps and faceted navigation.
- How
- Replace each pattern with
<a href="/path">, and keep buttons for actions that do not change the URL, such as adding to the cart or opening a dialog. Use URL fragments only where you deliberately do not want Google to follow, such as filter combinations. - How to test
- Search templates and the rendered HTML (DevTools Elements panel, URL Inspection) for
onclicknavigation,javascript:,routerLinkwithouthref,hrefonspanordiv, andhref="#/"; a JavaScript-rendering crawler finds no orphaned templates. - Sources
In Google's documentation
- Link best practices for Google
- Understand the JavaScript SEO basics
- Fix Search-related JavaScript problems
Said at Search Central Live
- ibramdawwa.de: Pass
- The server HTML of all 42 pages has no onclick links, no
javascript:URLs, no<a>withouthrefand no#pseudo-links.
Route single-page apps with the History API and real paths, not # fragments
Why · How · How to test · Sources
- Why
- A fragment (the part of a URL after #) exists only in the browser and is often ignored by crawlers, so hash-routed views are not separate pages for Google. Google recommends the History API for clean URLs.
- How
- Run the router in history mode: render links as
<a href="/path">, intercept the click, callhistory.pushStateand handlepopstate. Configure the server or hosting rewrites so a direct request to every valid path returns 200 with the page, ideally server-rendered, and unknown paths return 404. - How to test
- Open a deep URL directly in a fresh browser session and with curl: it returns 200 and the right content. The rendered HTML in URL Inspection contains no
href="#/..."routes. - Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Every page has a real path that returns 200 with its own content when opened directly; there are no #/ routes.
Link every indexable page from the normal navigation or a hub page
Why · How · How to test · Sources
- Why
- Google discovers pages through links and infers a page's importance from its internal links: how many point to it and how many clicks it is from the home page. A page reachable only through a sitemap is found slowly and attracts little crawl demand.
- How
- Link menus to category pages, category pages to sub-categories and those to every product or article, all with
<a href>, and keep important pages within a few clicks of the home page. Use the XML sitemap or a Merchant Center feed only as a supplement, never as the only way to reach a page. - How to test
- Crawl from the home page following only
<a href>links and compare the result with the sitemap: sitemap URLs missing from the crawl are orphans. Check the click depth of key templates. - Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- The link crawl from the home page found all 42 sitemap URLs, with no orphans, the deepest four clicks away.
Give each page of a paginated series its own URL, its own canonical and an
<a href>to the next pageWhy · How · How to test · Sources
- Why
- Google's crawlers do not click "next" buttons, and rel=next and rel=prev are no longer used. Pointing the canonical of page 2 and later at page 1 is incorrect because the pages are not duplicates, and items listed only on later pages may never be indexed.
- How
- Use ?page=n (or /page/n/) URLs with page 1 at the clean listing URL; each page carries a self-referencing canonical and
<a href>links to the next page and back to page 1. Never put page numbers in # fragments, and keep sort and filter variants out of the crawl. - How to test
- For pages 1 to 3 of a listing, curl the HTML: the canonical is self-referencing and the next-page
<a href>is present without JavaScript. URL Inspection shows later pages as indexable. - Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Not applicable
- The site has no paginated listings: /work shows every project on one page, and /work?page=2 canonicalises to /work.
Back infinite scroll and load-more buttons with paginated URLs
Why · How · How to test · Sources
- Why
- Google renders a page in a tall viewport instead of scrolling, and Googlebot does not click buttons. Content that appears only after scrolling further or clicking "load more" stays invisible unless each chunk also has its own URL.
- How
- Build load-more and infinite scroll on top of the paginated series: each chunk has a persistent URL that also works on direct load, chunks link to each other with
<a href>, and the History API updates the address when a new chunk becomes the main visible element. Trigger loading with an IntersectionObserver, never a scroll listener. - How to test
- With JavaScript disabled, follow the "more" link through every page of a listing. In URL Inspection the rendered HTML of page 1 contains a crawlable link to page 2, and server logs show Googlebot fetching the paginated URLs.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Not applicable
- There is no infinite scroll and no load-more button; every listing is complete in the server HTML.
Keep faceted navigation out of the crawl with robots.txt rules or URL fragments
Why · How · How to test · Sources
- Why
- Facets create near-infinite URL spaces (the same filters in another order, conflicting or excessive combinations) that burn crawl budget. Google's faceted navigation guide prefers prevention: disallow filter URLs in robots.txt or use URL fragments, which Google generally does not crawl; rel=canonical and nofollow are weaker, slower options.
- How
- Give only facets with real search demand an indexable landing page with a clean URL, unique content and
<a href>links. Put every other filter, sort and view parameter behind a robots.txt Disallow pattern or in the # fragment, also disallow internal search results and action URLs (cart, wishlist, compare), and audit CMS plug-ins for generated URL spaces. - How to test
- A crawl that respects robots.txt finds a bounded number of listing URLs, and server logs and Crawl stats show Googlebot not spending fetches on parameter URLs. Google's open-source robots.txt parser, run with the Googlebot token, returns disallowed for sample filter URLs and allowed for item pages.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Not applicable
- There is no faceted navigation and no filter or sort parameter; the crawl found no internal link with a query string.
Have all indexable content in the DOM after load, without clicks, typing or scrolling
Why · How · How to test · Sources
- Why
- Googlebot does not click, type or scroll, so content that loads only after a user action is not in the DOM when Google renders the page and cannot be indexed. Content that is in the DOM but hidden, such as tabs, accordions or read-more sections, can be.
- How
- Ship tab, accordion and read-more content in the initial HTML or DOM and hide it with CSS or the hidden attribute; never fetch it on click. Product specifications, reviews, FAQs and descriptions belong in the page at load.
- How to test
- In URL Inspection (rendered HTML) or the Rich Results Test, find text from every tab and accordion panel. In the DevTools Network panel, no content request waits for a click.
- Sources
In Google's documentation
- Fix lazy-loaded content
- Mobile site and mobile-first indexing best practices
- Understand the JavaScript SEO basics
Said at Search Central Live
- ibramdawwa.de: Pass
- All eight situation texts on /seo and both before/after pairs on / and /studio are now in the server HTML and in the rendered DOM without a click.
Lazy-load with native lazy loading or an IntersectionObserver, never with scroll events
Why · How · How to test · Sources
- Why
- Googlebot does not scroll, so a scroll event listener never fires and the content it would load never appears. Google renders with a very tall viewport instead, so content loaded when it enters the viewport does load during rendering.
- How
- Use
loading="lazy"on img and iframe elements, with a real src plus width and height, and an IntersectionObserver for other components. Never make indexable content depend on scroll position, scroll depth or a timer, and give long lists paginated URLs. - How to test
- The rendered HTML in URL Inspection contains below-the-fold images and list items. A code search finds no addEventListener('scroll') or onscroll handler that loads content.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Images use native lazy loading with a real src, no scroll handler loads content, and in a render without scrolling every counter shows its final value and no text block stays invisible.
Do not block JavaScript, CSS or API endpoints that pages need for rendering in robots.txt
Why · How · How to test · Sources
- Why
- Google's renderer fetches scripts, styles and API requests through Googlebot and obeys robots.txt: a resource it cannot fetch, it cannot run. A blocked script or /api/ folder leaves blank modules or an empty page, which can be treated as a soft 404 although users see a full page.
- How
- Allow all JS, CSS and font paths. If an API folder must stay disallowed, carve out the endpoints rendering needs (Disallow: /api/ plus Allow: /api/products/), check the robots.txt of every host the page loads data from, and re-test a rendered page after every robots.txt change touching script or API paths.
- How to test
- In the URL Inspection live test, no page resource needed for content is "Blocked by robots.txt". The DevTools Network panel (Fetch/XHR) lists each API host, and each host's robots.txt allows those paths.
- Sources
In Google's documentation
- Introduction to robots.txt
- Understand the JavaScript SEO basics
- Crawling December: the how and why of Googlebot crawling
- Inside Googlebot: crawling, fetching and the bytes Google processes
Said at Search Central Live
- ibramdawwa.de: Pass
- robots.txt blocks only /api/, which no page needs for rendering; scripts, styles and images are all crawlable.
Do not add, change or remove robots meta tags with JavaScript
Why · How · How to test · Sources
- Why
- Robots rules added with JavaScript take longer to be seen, and removing a noindex with JavaScript does not work: Google may skip rendering a page that arrives with noindex, so it stays out of the index. Google's documentation recommends not using JavaScript to inject or change meta tags.
- How
- Decide indexability on the server and send the final robots meta tag or X-Robots-Tag header in the first response; never ship noindex in the HTML shell and remove it after hydration. The one documented exception is adding noindex with JavaScript to an error view in a client-rendered app.
- How to test
- The robots meta tag in curl output and in URL Inspection's rendered HTML is identical on every indexable template. A search of the client bundle finds no code that writes
meta[name="robots"]except on error views. - Sources
In Google's documentation
- Meta tags and attributes that Google supports
- Understand the JavaScript SEO basics
- Robots meta tag, data-nosnippet, and X-Robots-Tag specifications
Said at Search Central Live
- ibramdawwa.de: Pass
- The robots meta tag is identical in the server HTML and the rendered DOM on every template checked, and no client code writes it.
Use noindex to keep a page out of Search, and leave that URL crawlable
Why · How · How to test · Sources
- Why
- robots.txt does not control indexing: a disallowed URL can still appear in results without its content when other pages link to it. And Google never sees a noindex on a page it may not fetch.
- How
- For pages that may be crawled but should not be indexed, send
<meta name="robots" content="noindex">orX-Robots-Tag: noindexin the server response and do not disallow the URL; use robots.txt only for URLs that should never be fetched. To de-index URLs that are already disallowed, add the noindex first, then remove the disallow so Google can see it. - How to test
- For each noindexed URL, URL Inspection shows Crawl allowed: Yes, curl shows the noindex, and the Page indexing report lists it as excluded by the noindex tag.
- Sources
In Google's documentation
- Block Search indexing with noindex
- Robots meta tag, data-nosnippet, and X-Robots-Tag specifications
- Introduction to robots.txt
Said at Search Central Live
- ibramdawwa.de: Pass
- Only the 404 page carries noindex, and robots.txt does not block it.
Do not use noindex, nofollow or crawl-delay to save crawl budget
Why · How · How to test · Sources
- Why
- noindex consumes crawl budget because Google must fetch the page to see it; nofollow is a hint, so linked URLs may still be crawled through other links or sitemaps; crawl-delay is not processed at all.
- How
- To stop Google fetching URLs on your own site, disallow them in robots.txt; return 404 or 410 for removed pages and consolidate duplicates with redirects or canonicals. Keep crawl rules stable instead of switching them to steer Googlebot around.
- How to test
- Server logs show few or no Googlebot fetches of parameter and action URLs, robots.txt has no crawl-delay meant for Google, and Crawl stats shows fewer fetches of low-value URLs after fixes.
- Sources
In Google's documentation
- Optimize your crawl budget
- Qualify your outbound links to Google
- How Google interprets the robots.txt specification
Said at Search Central Live
- ibramdawwa.de: Pass
- There is no nofollow and no crawl-delay anywhere; indexable pages carry only the permissive preview rules.
Do not add nosnippet or a short max-snippet unless you accept losing snippets and AI feature use
Why · How · How to test · Sources
- Why
- nosnippet removes the text snippet and video preview and also stops the page's content being used as a direct input for AI Overviews and AI Mode; max-snippet limits that use too. A page must be eligible for a snippet to be a supporting link in AI features.
- How
- Keep nosnippet and max-snippet limits off by default; to hide one detail, such as a phone number or a member price, use data-nosnippet on that element. If licensing requires limits, set them per template deliberately and record the trade-off.
- How to test
- Search the codebase, CMS settings and CDN transforms for nosnippet and max-snippet, and curl key templates to confirm none is present unless intended.
- Sources
In Google's documentation
- Robots meta tag, data-nosnippet, and X-Robots-Tag specifications
- AI features and your website
- Control your snippets in search results
Said at Search Central Live
- ibramdawwa.de: Pass
- No page uses nosnippet, and every indexable page sets max-snippet:-1, max-image-preview:large and max-video-preview:-1.
Put exactly one absolute rel=canonical in the server-rendered head of every indexable page
Why · How · How to test · Sources
- Why
- Google uses rel=canonical in deduplication and canonical selection but treats it as a strong hint, not an order, because the tag is so often wrong. With more than one canonical on a page, Google will likely ignore all of them.
- How
- Give every indexable page a self-referencing canonical with an absolute URL on the chosen origin, and point duplicates (tracking parameters, print views, sort orders) at the preferred URL. Output it from one layer only, in the server-sent head, with no invalid element such as an img or iframe before it, because Google stops reading the head there; for PDFs use an HTTP Link header.
- How to test
- A crawl finds no indexable page with zero or several canonicals or with a relative or placeholder value, and raw and rendered HTML carry the same canonical. URL Inspection shows the user-declared and the Google-selected canonical as equal on key templates.
- Sources
In Google's documentation
- How to specify a canonical URL
- 5 common mistakes with rel=canonical
- Use valid HTML to specify page metadata
Said at Search Central Live
- ibramdawwa.de: Pass
- All 42 sitemap URLs have exactly one absolute self-canonical in the server HTML, and the rendered canonical matches it.
Point every canonical directly at a final URL that returns 200, is indexable and is linked
Why · How · How to test · Sources
- Why
- Google can follow canonical chains but strongly recommends pointing every page directly at a single canonical. The target should carry no noindex, return no error, not be blocked in robots.txt and not redirect.
- How
- Resolve each canonical target to its final URL when pages are generated, and update canonicals after migrations or host changes. Never canonicalise to a URL that redirects, returns non-200, carries noindex or is disallowed, and make the canonical target the URL that internal links use.
- How to test
- Run a canonical audit in a crawler: group URLs by the final URL their canonicals and redirects lead to, and flag more than one hop, loops, several canonicals on one page, or a target that is noindexed, blocked, non-200, redirecting or not linked internally.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Every canonical points at its own URL, which answers 200, carries no noindex and is linked from the site.
Make all canonical signals agree: redirects, rel=canonical, internal links, sitemaps and hreflang
Why · How · How to test · Sources
- Why
- When all signals point to the same URL, Google follows the site owner; when they disagree, it cannot tell what the owner wants. Redirects and rel=canonical are strong signals, sitemap inclusion is a weak one, and combining them makes them more effective.
- How
- Generate canonical tags, sitemap entries, hreflang URLs and internal links from one URL-building function so they cannot drift apart, and check every signal against the preferred URL before a migration or template change.
- How to test
- A crawl finds no internal links to non-canonical URLs, no sitemap URLs that are not self-canonical and no hreflang targets that redirect or canonicalise elsewhere. Sampled URLs in URL Inspection show matching user-declared and Google-selected canonicals.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Internal links, the sitemap and hreflang all use the final URLs: no internal link hits a redirect or a non-canonical URL.
Do not canonicalise one language version to another; connect them with hreflang
Why · How · How to test · Sources
- Why
- A canonical from one language version to another asks Google to keep only one language in the index, so only that version would show. On pages with hreflang, the canonical should point to a page in the same language, or to the best substitute language if none exists.
- How
- Every language or country version keeps a self-referencing canonical and lists its alternates with hreflang. Check that no template falls back to the default-language canonical on translated pages.
- How to test
- In a canonical audit, no canonical group contains documents in more than one language, and every localised page's canonical equals its own URL.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Each English and German page canonicalises to itself and is connected to its counterpart with hreflang.
Redirect an old URL only to a page with the same intent, and return 404 or 410 when there is none
Why · How · How to test · Sources
- Why
- Google's site move guide warns against redirecting many old URLs to one irrelevant destination such as the home page, which can confuse users and may be treated as a soft 404, and says to return 404 or 410 for content that is not moved. A 200 on every new URL proves only that the URLs work, not that the content users came for is still there.
- How
- Before launch, freeze the URL inventory (CMS export, crawl, sitemaps, search data and logs) and approve a redirect map with one row per old URL: a same-intent target, or 404 or 410. After launch, test the live site against the map.
- How to test
- A script requests every old URL in the map and checks it returns one 301 to the mapped target, or the mapped 404 or 410. No old URL other than the old home page redirects to the new home page, and the Page indexing report shows no rise in soft 404s on redirect targets.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Partial
- /privacy and /en-home now lead to same-intent pages, but the old /services still redirects to the home page and the removed case /portfolio/etech-mobility to the /work listing instead of a 404 or 410.
Never route a crawlable URL's redirects through a URL that robots.txt blocks
Why · How · How to test · Sources
- Why
- Said at Search Central Live: robots.txt is checked for every URL in a redirect chain, and crawling stops at the first blocked one, for example in a shop that redirected every page through a disallowed /cart/ URL to set the currency. Search Console then reports the first URL of the chain as blocked by robots.txt, although that URL itself is not disallowed.
- How
- Set currency, language, consent or session state on the page itself or with a cookie, not with a redirect hop through cart, checkout, login or tracking URLs. Point every redirect straight at its final URL, re-check the redirect map whenever robots.txt gains a Disallow rule, and never redirect Googlebot differently from users.
- How to test
- When Search Console reports a URL as blocked by robots.txt that the file does not block, follow its redirect chain hop by hop with a browser and a Googlebot user agent, and test every hop against its own host's robots.txt with Google's open-source parser. JavaScript redirects only show in a rendered check, such as the URL Inspection live test.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- robots.txt blocks only /api/, and no redirect on the site passes through it.
Return 404 or 410 for removed and non-existent URLs
Why · How · How to test · Sources
- Why
- URLs that return 4xx codes (other than 429) are not indexed and do not slow crawling, and a 404 is a strong signal not to crawl the URL again. A soft 404 is kept out of the index but keeps being crawled, wasting crawl budget.
- How
- Answer unknown paths, deleted items without a close replacement and invalid parameters with 404 or 410 and a helpful error page (search box, main categories). Redirect only when a genuinely equivalent replacement exists, and never send every missing URL to the home page.
- How to test
- curl -I https://www.example.com/this-does-not-exist-123 returns 404, and the soft 404 count in the Page indexing report stays near zero.
- Sources
In Google's documentation
- How HTTP status codes affect Google's crawlers
- Optimize your crawl budget
- Troubleshoot Google Search crawling errors
Said at Search Central Live
- ibramdawwa.de: Pass
- Made-up URLs at every depth answer 404 with a noindexed error page, and so do leftovers of the old site such as /blog and the old /porfolio/ stories.
Return a real 404 for unknown routes in single-page apps, or use a documented client-side fallback
Why · How · How to test · Sources
- Why
- In single-page apps the server often returns the app with 200 for every URL while the router shows a "not found" view, so no error is reported. When a server-side 404 is impractical, Google documents two fallbacks: a JavaScript redirect to a URL that returns 404, or a noindex robots meta tag added with JavaScript.
- How
- Prefer the server: route known paths, look up dynamic ones such as product slugs, and send the app shell with 404 for everything else. Otherwise, redirect error views in the client to a URL the server answers with 404, or inject
<meta name="robots" content="noindex">on error views. - How to test
- curl -I on a made-up deep URL returns 404, or the rendered HTML in URL Inspection shows the redirect or the noindex. The Page indexing report shows no soft 404s on app routes.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Unknown deep routes such as /de/work/nope or /work/concepts/trace/nope get a real 404 from the server.
Never serve error states, empty results or failed data loads with a 200 status
Why · How · How to test · Sources
- Why
- Common causes of soft 404s are pages that look like errors, thin or empty content, server or CMS misconfiguration, and JavaScript-dependent content that fails to load. Said at Search Central Live: detection understands page layout, so an error message alone in the main content makes a soft 404 even when header and navigation look normal.
- How
- Database and backend failures return 503, missing content returns 404 or 410, and empty search and filter results return 404 or carry noindex. Client-rendered pages whose data request fails show a retry option and never leave an empty main area on a 200 URL.
- How to test
- In staging, simulate a backend outage: pages answer 503, not 200. Crawl for 200 pages with very short main content or error wording, and review the soft 404 list in the Page indexing report after each release.
- Sources
In Google's documentation
- Troubleshoot Google Search crawling errors
- How HTTP status codes affect Google's crawlers
- Crawling December: CDNs and crawling
Said at Search Central Live
- ibramdawwa.de: Pass
- Pages are prerendered and load no data per request, and no 200 page shows an error state; the 503 answer for an outage is configured but has not been drilled.
Give every language and country version its own URL
Why · How · How to test · Sources
- Why
- Switching languages with cookies or by swapping content in place makes the versions very hard for Google to handle. Googlebot mostly crawls from US IP addresses without an Accept-Language header, so content that adapts to the visitor may never be crawled in its other versions.
- How
- Give each version its own URL (example.de, de.example.com or example.com/de/), never a ?lang= parameter or a cookie. The URL alone decides the language and region served; a remembered choice may only preselect the language selector.
- How to test
- curl each version's URL from one location with no Accept-Language header and no cookies: each returns its own language and content.
- Sources
In Google's documentation
- Managing multi-regional and multilingual sites
- How Google crawls locale-adaptive pages
- Tell Google about localized versions of your page
Said at Search Central Live
- ibramdawwa.de: Pass
- English lives at clean URLs and German under /de, and without cookies or Accept-Language each URL returns its own language.
Do not redirect visitors automatically by IP address or browser language
Why · How · How to test · Sources
- Why
- Googlebot mostly crawls from the US without an Accept-Language header, so automatic redirects can hide every other version from it. Said at Search Central Live: Google advised against clever geo-redirecting because it very often goes wrong.
- How
- Serve the requested URL as it is and suggest another version with a dismissible banner or the language selector. Point x-default at a language selector or a generic page instead of redirecting from the root.
- How to test
- curl -I on each country URL with IP addresses or Accept-Language headers of other countries returns no 3xx to another version.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Requests to one language version with the other language (or French) in Accept-Language get 200, never a redirect.
Make hreflang complete: a self-reference, return links and fully qualified URLs
Why · How · How to test · Sources
- Why
- Google ignores hreflang annotations that point only one way, and missing return links and missing self-references are common mistakes. Alternate URLs must be fully qualified, including https://, and may be on other domains.
- How
- Every page in a set lists itself and every alternate with an identical block, plus x-default for the fallback or selector page. Point only at canonical, indexable 200 URLs and generate the block for all versions from one data source.
- How to test
- An hreflang audit in a crawler reports, per cluster, no missing return links, no missing self-references, no non-200 or non-canonical targets and no relative URLs.
- Sources
In Google's documentation
- Tell Google about localized versions of your page
- How Google knows what language to show in search results
Said at Search Central Live
- ibramdawwa.de: Pass
- Every page lists en, de and x-default as absolute URLs including itself, and every target links back.
Use valid hreflang codes: an ISO 639-1 language, an optional ISO 15924 script and an optional ISO 3166-1 Alpha-2 region
Why · How · How to test · Sources
- Why
- Common mistakes are country codes used as languages (se, dk and cz instead of sv, da and cs), wrong regions (UK instead of GB, GE instead of DE) and regions that are not countries, such as EU. Some mistakes are valid codes for something else (se is Northern Sami, GE is Georgia) and silently target the wrong audience.
- How
- Store each version as a language plus an optional script and region (sv-SE, de-CH, en-GB, zh-Hant, zh-Hans-CN), validate every value against the ISO 639-1, ISO 15924 and ISO 3166-1 Alpha-2 lists in a build check or crawler rule, and use x-default for everyone else.
- How to test
- An automated check finds every value matching x-default or language[-Script][-REGION] (case-insensitive), with each part listed in ISO 639-1, ISO 15924 or ISO 3166-1 Alpha-2.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- The only hreflang values are en, de and x-default, all valid.
Build language and market selectors as
<a href>links to each alternate URLWhy · How · How to test · Sources
- Why
- A selector built as a button works for users but leaves the alternate-language pages without crawlable links, so they are orphaned for Google and depend on sitemaps to be found, which is slow.
- How
- Render the selector as a list of
<a href>links to the equivalent page in each version, not only to each version's home page, and keep any visual dropdown on top of those real links. - How to test
- The rendered HTML of any page contains
<a href>links to every version of that page, and a crawl starting from one version reaches all the others. - Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- The language switch on every page is an
<a href>to the same page in the other language.
Give every indexable page a unique, descriptive title element in the server HTML
Why · How · How to test · Sources
- Why
- Indexing analyses a page's text and key tags such as the title element, and Google generates title links from its understanding of the page. It notices a changed title only after recrawling and reprocessing the page, which its title link guide says takes a few days to a few weeks.
- How
- Generate the title on the server from the page's own data, with no placeholders, no HTML and no duplicates across a template, and keep it descriptive and specific to the page. Generate a plain-text meta description per page the same way: Google uses it only sometimes, but a broken one still reaches results.
- How to test
- A crawl finds no missing, duplicate, empty or placeholder titles, and no meta description that contains < or > or a placeholder.
- Sources
In Google's documentation
- In-depth guide to how Google Search works
- Control your snippets in search results
- SEO Starter Guide
- Influencing your title links in search results
Said at Search Central Live
- ibramdawwa.de: Pass
- All 42 titles are in the server HTML and unique; the English legal notice now has a title of its own.
Never hide text from users, such as white-on-white or off-screen keyword blocks
Why · How · How to test · Sources
- Why
- Hidden text is against Google's spam policies, and sites that violate them may rank lower or not appear at all. Said at Search Central Live: Google records spam signals such as white-on-white text with a page's tokens, so leftover hidden keyword blocks are a liability.
- How
- Remove hidden keyword blocks, text in the background colour and text positioned off-screen for search engines. Legitimately hidden interface content, such as tabs, accordions and screen-reader-only labels, is fine.
- How to test
- A crawl with a style check finds no text whose colour matches its background and no off-screen or display:none blocks outside accessibility helpers and UI components.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Text not in view is limited to screen-reader labels, the closed menu, inactive tabs and panels and the last card of a horizontal gallery, and a rendered scan of 14 templates found no text in its background colour.
Mark up only content that is visible on the page and relevant to it
Why · How · How to test · Sources
- Why
- Google's guidelines say not to mark up content that readers cannot see, even if it is accurate. Irrelevant or misleading markup can lead to a manual action that removes rich result eligibility, without affecting web ranking.
- How
- Generate markup from the same fields that render the visible content, use it for the machine-precise form of visible facts (an ISO date for a shown date, the home page url for a named organisation), and remove markup for content a page no longer shows.
- How to test
- For each template, the Rich Results Test output matches what the page visibly shows, and the Manual actions report in Search Console is empty.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Each structured-data item matches visible content: the FAQ answers, the films on their watch pages and the client named on the CDM case page are all on the page.
Validate markup in the Rich Results Test before it reaches templates, and monitor it after release
Why · How · How to test · Sources
- Why
- Google recommends testing structured data in the Rich Results Test, and testing manually, before putting markup into templates. AI-generated markup can contain invented properties or broken nesting and should be fact-checked and validated before publishing.
- How
- Prototype each type on one page, validate it, then put it in the template; for staging and other private pages paste the rendered HTML into the test, since it cannot load resources behind a firewall or password. Fix every error, add a CI step that checks the JSON-LD of rendered templates for syntax and required properties, and review the rich result reports in Search Console after each release.
- How to test
- The Rich Results Test passes for one URL per template, and CI fails on JSON-LD parse errors or missing required properties.
- Sources
In Google's documentation
- Rich Results Test
- Introduction to structured data markup in Google Search
- Guidance on using generative AI content
- Rich result report overview
Said at Search Central Live
- ibramdawwa.de: Fail
- All JSON-LD on the 42 pages parses, but no Rich Results Test run is on record and the deploy pipeline checks only status codes, not structured data.
Do not mark up self-serving review ratings of your own business
Why · How · How to test · Sources
- Why
- Under Google's review snippet guide, ratings of local businesses and organisations are eligible only on sites that capture reviews about other businesses. Reviews a business shows about itself are self-serving and not eligible.
- How
- Generate Review and AggregateRating markup only from reviews visible on the page, for example on product pages, and remove LocalBusiness or Organization ratings about your own business from the site's markup, including those added by review widgets.
- How to test
- The Rich Results Test shows review snippets only on templates with visible reviews, and a crawl finds no rating on the site's own Organization or LocalBusiness entity.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- No page marks up ratings or reviews, neither on the company entity nor anywhere else.
Put every image that should be found in an
<img>element with asrcattributeWhy · How · How to test · Sources
- Why
- Google finds images by looking for img elements, and src is the most important attribute: without it Google does not know where the image is. The picture element is supported only through the img it contains, and CSS background images are not extracted.
- How
- Content images use img with src, inside picture where art direction or modern formats are needed; keep CSS backgrounds for decoration. Lazy-loaded images keep a real
srcwithloading="lazy", not only adata-srcfilled in by a script. - How to test
- In the rendered HTML (URL Inspection) key images are img elements with a src, and a template search finds no background-image on content images.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Every content image is an
<img>with a realsrcand dimensions; CSS backgrounds serve only as blur placeholders and one decorative poster.
Describe every meaningful image in its alt attribute
Why · How · How to test · Sources
- Why
- Google calls alt text the most important attribute for image metadata and uses it, with computer vision and the page content, to understand the image. Alt text should describe the image for someone who cannot see it.
- How
- Make alt text a required CMS field for content images, write specific descriptions rather than file names or keyword lists, and give decorative images an empty
alt="". If you generate alt text with an LLM, review a sample first and give the model the page title as well as the image. - How to test
- A crawl finds no content image with a missing alt, an empty alt or an alt equal to the file name, and the axe or Lighthouse image-alt check passes.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Every case, client and concept image now has a specific alt text in both languages; empty alts remain only on hover layers, link thumbnails beside the project name, one device mock-up frame and a labelled collage, all of them images described on their own project pages.
Embed each video in a video, iframe, embed or object element that loads without user action
Why · How · How to test · Sources
- Why
- Google finds videos referenced in these elements and extracts the video with the data around it. A video that loads only after a click, swipe or typing is not found.
- How
- Output the player element in the HTML at load (a poster frame is fine), at its real size and position and not hidden behind other elements; for lazy players keep the element and its src or embed URL in the DOM. The Video indexing report flags "Cannot determine video position and size" when the player is not on the page at load.
- How to test
- The rendered HTML in URL Inspection contains the video element or iframe with its URL, and the Video indexing report lists the page.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Both films are now a
<video>element with its file URL in the page at load (preload none), on their own watch pages and on the parent pages; the Video indexing report was not read for this check.
Never manipulate browser history so that Back does not return users to where they came from
Why · How · How to test · Sources
- Why
- Back button hijacking, interfering with browser navigation so users cannot use Back to return to the page they came from, violates Google's malicious practices spam policy and has been enforced since 15 June 2026 with manual actions or automated demotions. Google says the cause can be a site's included libraries or advertising platform.
- How
- Call history.pushState only for real in-app navigation that the user triggered, never on page load, on scroll or to insert interstitial or exit pages, and do not intercept popstate to keep users on the site. Audit scripts from ad, engagement and recommendation vendors and remove any code that adds history entries.
- How to test
- An automated browser test opens each template from another page, interacts, presses Back once and lands on the previous page. A code search of the built bundles finds no pushState or replaceState outside the router.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- For 13 templates, opening the page from another page, interacting and pressing Back once always returned to the previous page.
Do not generate large sets of low-value pages from templates, feeds or LLM output
Why · How · How to test · Sources
- Why
- Scaled content abuse, many pages generated mainly to manipulate rankings rather than help users, violates Google's spam policies whether the pages come from generative AI, scraped feeds or stitched sources. Said at Search Central Live: Google counts AI slop as scaled content abuse.
- How
- Put programmatic page types (location by service, product by keyword, one page per question) behind a review: each page needs unique, useful main content, otherwise do not create it or keep it noindexed. Do not auto-publish LLM drafts or feed-derived pages in bulk, and require an editor's approval per page.
- How to test
- A crawl of each programmatic template finds no clusters of near-identical pages, publishing logs show an editor's approval for generated pages, and the Manual actions report in Search Console is empty.
- Sources
In Google's documentation
- Spam policies for Google web search
- Guidance on using generative AI content
- Creating helpful, reliable, people-first content
Said at Search Central Live
- ibramdawwa.de: Pass
- The site has 42 individually written pages in two languages and no page sets generated from templates or feeds.
Never serve Googlebot different content from users, and do not build doorway pages
Why · How · How to test · Sources
- Why
- Cloaking (showing different content to users and to search engines to manipulate rankings) and doorways (pages created to rank for similar queries that lead users to less useful intermediate pages) are spam types in Google's spam policies.
- How
- Never branch on the Googlebot user agent or Google's IP ranges to change text, links or redirects. Do not generate near-identical city or keyword landing pages that funnel visitors to one destination; merge them into one useful page per real offering.
- How to test
- The HTML served to a Googlebot user agent and to a browser has the same main content, links and redirects, and the rendered HTML in URL Inspection matches what users see.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Googlebot, Bingbot, GPTBot and a browser receive byte-identical HTML, and there are no doorway pages.
Verify every production host in Search Console before launch
Why · How · How to test · Sources
- Why
- Debugging what Google sees on a site, with URL Inspection, the Page indexing report or Crawl stats, starts with verified access to the site in Search Console.
- How
- Add a Domain property (DNS verification) that covers every subdomain and protocol, plus URL-prefix properties for sections or hosts that need separate access, and keep the verification record in infrastructure code so it survives DNS or CMS changes.
- How to test
- Search Console lists the Domain property as verified, and every team that ships code has access.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- A Search Console Domain property has been verified since 10 Oct, and its verification TXT record is publicly visible in DNS; who on the team has access cannot be seen from outside.
Launch day
Answer planned maintenance and short outages with 503, for a day or two at most
Why · How · How to test · Sources
- Why
- 5xx and 429 responses make Google slow down temporarily and keep indexed URLs for a while, but URLs that keep failing are eventually dropped; a 200 "we'll be back soon" page becomes a soft 404 or replaces your content in the index, and a 404 removes the URLs. Said at Search Central Live: Google lowers a site's crawl capacity within about four hours of a burst of 500 errors, while increases take one to three weeks.
- How
- During maintenance or the switch-over, return 503 for every page (Retry-After is optional), keep robots.txt answering normally and limit the 503 period to one or two days. For a longer pause keep the site online with reduced functionality, and never use 503 or 429 as a permanent throttle.
- How to test
- In a maintenance drill, curl -I on any page returns 503 while curl -I on /robots.txt returns 200. Afterwards, the 5xx share in Crawl stats falls back to zero.
- Sources
In Google's documentation
- Temporarily pause or disable a website
- How HTTP status codes affect Google's crawlers
- Debug network and DNS errors for Google's crawlers
- Reduce the Google crawl rate
Said at Search Central Live
- ibramdawwa.de: Partial
- According to the server runbook of 10 Oct, nginx answers 503 with Retry-After and serves robots.txt itself while the app container is down, but we have not yet confirmed this in a maintenance drill.
Use permanent server-side redirects (301 or 308) for moved URLs, straight to the final URL
Why · How · How to test · Sources
- Why
- Redirects are a strong signal when Google picks the canonical URL, and their type matters: with a temporary redirect Google keeps showing the source URL. Google's crawlers follow up to 10 redirect hops, long chains hurt crawling, and JavaScript redirects are only seen after rendering, if at all.
- How
- Answer every moved, merged or renamed URL with one 301 or 308 to the final URL, and collapse old chains in the redirect map into single hops. Update internal links, canonicals, hreflang and sitemaps to the new URL, use 302 or 307 only for genuinely temporary moves, and avoid meta refresh and JavaScript redirects for permanent ones.
- How to test
- curl -sIL on an old URL shows one 301 or 308 hop ending in 200, and a crawler's redirect-chain report is empty. After recrawl, URL Inspection of the new URL shows it as the Google-selected canonical.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Partial
- Every old https URL, on www or the apex, now reaches its new page in a single 308, but http://www variants of old paths and trailing-slash variants still take two hops, so the kit's no-chains test is not fully met.
Serve one host over HTTPS with a valid certificate and redirect every other origin to it
Why · How · How to test · Sources
- Why
- The www and non-www versions of a page are exact duplicates that Google clusters, keeping one. Whether a page loads properly counts in canonical selection, so a broken certificate counts against a URL.
- How
- Pick one origin (for example https://www.example.com), redirect every other combination of protocol and host name with a single 301, and serve a valid TLS certificate on every host name that answers, including the redirecting ones. Use only the chosen origin in internal links, canonicals, hreflang and sitemaps, and enable HSTS once HTTPS works everywhere.
- How to test
- curl -I on http://example.com, http://www.example.com and https://example.com each returns one 301 to the https://www. URL, and a TLS check (openssl s_client or an online scanner) shows a valid certificate on every host name.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- http on both host names and https://www each reach https://ibramdawwa.de in one hop, the certificate covers both names, and the bare IP and unknown host names are refused.
Never leave staging, preview or mirror copies of the site publicly crawlable
Why · How · How to test · Sources
- Why
- A crawlable copy, such as a staging site, competes with production for canonical selection and can win. Google watches for several domains trying to be canonical for the same content, including a site owner's own copies.
- How
- Protect staging, preview and QA environments with HTTP authentication or an IP allowlist, since a 401 or 403 cannot be indexed, and add a site-wide noindex header as a second layer. Never launch with staging's blanket noindex or Disallow: / still in place, and never point production canonicals or hreflang at a staging host.
- How to test
- curl -I on the staging host returns 401 or 403 without credentials, and the pre-launch check shows that production has no global noindex and no Disallow: /.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- No staging or preview host is public, and the bare server IP, which still served a full copy of the site on 9 Oct, now refuses the connection.
Render every template in a headless browser before release and check it in URL Inspection right after
Why · How · How to test · Sources
- Why
- The rendered HTML in Google's testing tools shows what Google can index, and the live test also shows page resources, JavaScript console messages and a screenshot. URL Inspection tests only public URLs of a verified property, so it cannot test a staging host behind a password.
- How
- Keep one representative URL per template (home, category, product, article, landing pages, each language version). Before release, render each template on staging with headless Chrome (Puppeteer or Playwright), compare raw and rendered DOM and collect console errors; right after release, run the URL Inspection live test on one production URL per template and check rendered HTML, resources and console messages.
- How to test
- The release checklist records a headless render result for each template before release and a URL Inspection live test result for each template after release.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Partial
- Headless render scripts exist and were run by hand on 9 and 13 Oct, but the deploy pipeline still checks only status codes and no per-template URL Inspection result is recorded.
In the weeks after
Keep pages indexable and snippet-eligible, the whole technical requirement for AI features
Why · How · How to test · Sources
- Why
- To appear as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown with a snippet; there are no additional technical requirements. AI features are built on Google's core ranking systems and its index.
- How
- Apply the rest of this checklist, do not block snippets, and keep the generative AI setting in Search Console on include unless the site is excluded on purpose. When a page never shows up as a source, check indexing, snippet rules and that setting first.
- How to test
- URL Inspection shows the page as indexed, its robots rules contain no nosnippet, and the Generative AI performance report in Search Console shows impressions.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Pass
- Every indexable page answers 200, is self-canonical, allows full snippets and has its copy in the server HTML; indexing and AI impressions show only in Search Console, which we did not read for this check.
Keep the CMS and plug-ins patched and watch for injected pages and links
Why · How · How to test · Sources
- Why
- Hacked content, placed on a site without permission through security vulnerabilities, is one of the spam types in Google's policies; cleaning it up is hard, so prevention is key. If it leads to a manual action, Google's help says most reconsideration reviews take several days or weeks.
- How
- Automate CMS, theme and plug-in updates, remove unused plug-ins and accounts, require two-factor login for editors, and alert on new URLs, outbound links or sitemap entries that no editor created. After a clean-up, file the reconsideration request only once every injected page and link is gone.
- How to test
- A weekly comparison of the sitemap and a crawl with the CMS's own page list finds no unknown URLs, and the Security issues and Manual actions reports in Search Console are empty.
- Sources
In Google's documentation
Said at Search Central Live
- ibramdawwa.de: Partial
- There is no CMS or plug-in, production dependencies have no known vulnerabilities and today's crawl found no unknown URLs or outbound hosts, but no scheduled crawl comparison or dependency update bot is set up in the repository.
ibramdawwa.de
How our own site does
We checked ibramdawwa.de against this list ourselves. Each item shows our result on the day of the check, including where we still have work to do.
- Pass
- 47
- Partial
- 5
- Fail
- 1
- Not applicable
- 3