# iviG Technical SEO — Full Site Content > SEO consulting and technical implementation by Milan Georgijevic. Services include SEO audits and action plans, technical SEO fixes and ongoing SEO support. A free initial website review covers a small selection of public pages, with up to five priority findings or next steps by email; it is not a comprehensive audit. Site: https://ivig.dev/ Contact: milan@ivig.dev This file contains the full text content of the site's main pages for AI answer engines. Short index: https://ivig.dev/llms.txt --- ## Homepage URL: https://ivig.dev/ iviG Technical SEO is the consulting practice of Milan Georgijevic, an SEO consultant with a software development background. Work directly with Milan to diagnose issues, implement agreed changes or collaborate with your developer. ### Services - SEO audit and action plan: technical barriers, content, internal links and Search Console data when access is available. Deliverables are findings, priorities and a practical roadmap. - Technical SEO fixes: indexing, canonicals, redirects, page performance and structured data. Deliverables are agreed changes and validation checks. - Ongoing SEO support: content planning, existing-page improvements, internal linking and search performance reviews. Deliverables are an agreed work plan, implementation and progress reviews. - Paid scope, deliverables and price are agreed before work begins. ### The free website review A personal first look at a small selection of public pages, with up to five priority findings or next steps by email. This is not a full-site crawl, comprehensive audit or implementation service. No login is needed. Search Console and analytics analysis require separate permission to view the data. Milan replies by email to confirm next steps and timing; there is no obligation to buy. Request it at https://ivig.dev/#free-audit with your website address, name and email. Do not send passwords. ### About Milan and his approach Milan's software development background helps connect SEO recommendations to the site's actual implementation. The workflow is to find the cause, agree on priorities and scope, implement changes, then validate and review relevant search and enquiry data. Technical fixes do not guarantee rankings or leads. Upwork: https://www.upwork.com/freelancers/milang67 LinkedIn: https://www.linkedin.com/in/milan-georgijevic-75818b273/ For paid projects, email milan@ivig.dev with your website, what you would like to improve and any deadline. ### Learn SEO: start here 1. How Google Search works: https://ivig.dev/how-google-search-works/ 2. Search intent explained: https://ivig.dev/search-intent-guide/ 3. Keyword research for beginners: https://ivig.dev/keyword-research-guide/ 4. SEO titles and meta tags: https://ivig.dev/on-page-seo-guide/ All guides: https://ivig.dev/seo-guides/ For an example of Milan's audit approach, read https://ivig.dev/seo-audit-checklist/ ### TechSEO Inspector (free Chrome extension) Milan's free Chrome extension helps inspect page titles, headings, links and structured data. Its score summarizes checklist results, not Google's ranking assessment, and does not replace a full audit. Details: https://ivig.dev/techseo-inspector/ Install: https://chromewebstore.google.com/detail/techseo-inspector/pamgfjigokjaffaeldmgbiimjgjfmppj ### Frequently asked questions **Do I need an SEO audit or help with a specific problem?** If you already have a clear issue or an audit, we can discuss implementation directly. If you're unsure what's holding your site back, start with the free review. A paid audit is for a more detailed investigation and prioritized plan. **What does the free website review include?** A personal review of a small selection of public pages, with up to five priority findings or next steps sent by email. It is an initial assessment, not a full-site crawl, comprehensive audit or implementation service. There is no obligation to buy a service. **Do you need access to my website or Search Console?** No access is needed for the initial public-page review. Search Console and analytics analysis require permission to view your data. For a paid project, we'll agree on the minimum access needed before work starts. Don't send passwords through this form or by email. **Can you implement the fixes or work with my developer?** Both. I can implement agreed technical changes directly or work with your developer using a clear fix list and validation steps. We'll confirm your platform, access, scope and testing arrangements first. **Do you guarantee rankings or a timeline for results?** No. Search visibility depends on your site, competitors and search engines. We can verify whether an agreed fix works, but that doesn't guarantee rankings, traffic or leads. We'll choose relevant measures and review progress against your starting point. **How much do paid services cost?** Pricing depends on the size of your site, the problem and the work involved. After discussing your website, I'll propose a scope, deliverables and price for you to approve before paid work begins. --- ## Free Tools hub URL: https://ivig.dev/tools/ Index of free SEO tools built by iviG. No email wall, no premium tiers, no accounts. Lists TechSEO Inspector, a Chrome extension for on-page checks, and Sitemap Scout, a web app for sitemap health checks. ## Sitemap Scout (free XML sitemap checker) URL: https://ivig.dev/sitemap-scout/ Launch: https://scout.ivig.dev/ Home (https://ivig.dev/)/Free Tools (https://ivig.dev/tools/)/Sitemap Scout Free web app · No installation # Sitemap Scout: Free XML Sitemap Checker Find the URLs that need attention in your sitemap. Check for broken links, redirects, noindex pages and canonical mismatches, then export a report you can work through. Open Sitemap Scout ↗ (https://scout.ivig.dev/)Free. No account. Up to 25 URLs per scan. Built by Milan Georgijevic at iviG (https://ivig.dev/#about). A focused sitemap health check for site owners, developers and SEO practitioners. (https://ivig.dev/assets/tools/sitemap-scout-overview.webp) Actual Scout interface. The built-in Atlas report uses fictional data to demonstrate common issues. Select any screenshot to view it full size. How to use it (https://ivig.dev/sitemap-scout/#how-it-works)What it checks (https://ivig.dev/sitemap-scout/#checks)Example report (https://ivig.dev/sitemap-scout/#example)Limits & privacy (https://ivig.dev/sitemap-scout/#limits)FAQ (https://ivig.dev/sitemap-scout/#faq) 25 Page URLs checked per scan, at most. 3 Sitemap documents per scan, at most. CSV / JSON Export formats for reviewing and keeping results. No account Open the app and enter a public sitemap URL. Why check your sitemap? ## A sitemap can load correctly and still list the wrong URLs A working XML file is only the starting point. A deleted product, an old address that now redirects, or a page set to noindex can remain in a sitemap after the website changes. Scout helps you find those contradictions in the URLs it checks. Google recommends including the canonical URLs you want to appear in search results. A sitemap is a discovery signal, not an indexing guarantee. Scout gives you a practical way to review the listed pages before investigating their status in Search Console. Google's sitemap guidance (https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) explains the underlying rules. Use it after removing pages, changing URL structures, adjusting canonical tags or updating your CMS's sitemap settings. For the broader setup process, see the XML sitemap guide (https://ivig.dev/xml-sitemap-guide/). Three steps ## How to check an XML sitemap 1 ### Enter your sitemap URL Open Scout and paste the full address of a public sitemap or sitemap index. Use the XML file's URL, rather than your homepage. If you only want to explore the interface, select “Try an example.” → 2 ### Run the health check Select “Run health check.” Read the checked and discovered counts first, then use the errors, warnings and healthy filters to focus the results. A capped scan does not cover every URL on a larger site. → 3 ### Inspect, export and fix Open a result's details to see its status, canonical and robots signal. Download CSV or JSON before closing the tab. Make changes in your website or sitemap generator, then run another check. Check your sitemap (https://scout.ivig.dev/) Checks and next steps ## What Sitemap Scout checks, and what to do with a finding Each result is evidence to review. A warning may describe an intentional setup, and one request can be affected by temporary server conditions. Confirm the intended behavior before making changes. HTTP status ### Broken links A listed page may return a 404 instead of the content you expected. If the page was removed intentionally, remove its URL from the sitemap. If it should still exist, investigate the missing page or routing problem. Don't redirect every missing page to the homepage just to hide an error. Read the HTTP status codes guide (https://ivig.dev/http-status-codes-guide/). Destination ### Redirects A redirect can be correct for visitors using an old address. The sitemap should normally list the intended final canonical URL. Check the destination, confirm it is the page you want indexed, and update the sitemap source so the old entry does not return the next time it regenerates. Indexing directive ### Noindex pages A noindex directive tells a search engine not to index the page. Decide whether that exclusion is deliberate. If it is, remove the page from your indexable sitemap. If it is accidental, fix the directive and recheck. A successful HTTP response alone does not make a page indexable. See Google's noindex documentation (https://developers.google.com/search/docs/crawling-indexing/block-indexing). Preferred URL ### Canonical mismatches The URL in the sitemap may declare another address as canonical. That can happen with parameterized URLs or duplicate paths. Inspect both addresses and align the sitemap with the preferred version. Don't change a valid canonical simply to make a warning disappear. The canonical URL guide (https://ivig.dev/canonical-url-guide/) explains how to choose a version. Response timing ### Slow responses Scout shows how long its request took and flags slow responses. Use this as a reason to investigate or repeat the check. It is not a Core Web Vitals measurement, a browser rendering test or a record of real visitors' experience. For that work, follow the Core Web Vitals guide (https://ivig.dev/core-web-vitals-guide/). Scan coverage ### Sitemap structure and scope Check that you supplied a public sitemap document and review any scan-level message before relying on the page results. Compare discovered URLs with checked URLs. The public service stops at its document and URL limits; a clean subset does not establish that every sitemap or page on the website is healthy. Further reference: how Google handles HTTP status codes (https://developers.google.com/crawling/docs/troubleshooting/http-status-codes) and Google's canonicalization guidance (https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls). Inside the report ## Filter the noise. Read the actual finding. The example report starts with 10 checked URLs: 5 healthy, 2 errors and 3 warnings. Selecting “Warnings” narrows the table to a redirect, a slow response and a canonical mismatch. Each row keeps the URL, HTTP status and response time together. Search helps you find a particular path when reviewing results. The CSV and JSON controls let you keep a copy outside the temporary report. These screenshots show the built-in demonstration, not a scan of a customer's website. (https://ivig.dev/assets/tools/sitemap-scout-warnings.webp)Warnings filter, URL search and export controls in the real app. Example data. ## A 200 response can still need attention In this example, a collection URL with a query string returns HTTP 200, but its canonical points to the clean collection address. The details panel puts that canonical beside the response time and robots signal, making the disagreement visible. If the clean address is the intended canonical, list it in the sitemap. If the alternate URL is meant to be a distinct page, investigate its canonical configuration first. A mismatch is a prompt to check the site's intended structure, not an instruction to remove every query string. (https://ivig.dev/assets/tools/sitemap-scout-detail.webp)An expanded canonical mismatch from the fictional Atlas example. Query values are hidden. From report to repair ## Turn sitemap findings into a short fix list - Confirm the page's purpose. Should it exist, and should it be eligible for search? That determines whether to restore the page, correct a directive or remove the sitemap entry. - Fix the source of the entry. Change the CMS settings, generator rule or source file. Editing a generated XML file by hand may only last until its next rebuild. - Check the preferred URL again. Confirm its response and canonical, then run Scout on the updated sitemap. Save the new export if you need a record of what changed. - Follow up in Search Console. Use Google's reports to investigate indexing. Scout can show a technical change in a fresh request; it cannot tell you when Google will recrawl or index the page. A healthy result is scoped to the check. Scout is not a full site crawler. It does not establish that unlisted pages are discoverable, assess content quality or prove that Google selected your preferred canonical. If a page still does not appear in search, work through the page not indexed guide (https://ivig.dev/page-not-indexed/). Limits & privacy ## Know what the public scan covers Each scan checks up to 25 URLs across 3 sitemap documents. The public app allows 5 scans per IP per hour, 20 per IP per day and 150 scans per day overall. Shared networks can share an IP allowance. Check the app's current limits notice before planning a larger review. Scout runs through a web interface, but the scan is processed on a server. Full URLs are temporarily stored to perform the check. Query values are hidden in reports; URL paths and page titles remain visible. Submit public URLs only, without passwords, access tokens or private information. Reports require a private access token and expire after one hour. Expired files are removed on later scan activity. Hosting logs and backups may have separate retention. Download any report you want to keep before closing the tab. The Scout app has no accounts, analytics, cookies or paid API integrations. That describes the app at scout.ivig.dev; this informational website has its own privacy policy (https://ivig.dev/privacy-policy.html). You can review the app's “Scan limits & privacy” section before starting. Use the right check ## Scout, TechSEO Inspector or a full audit? Use Sitemap Scout when your question is whether the URLs listed in a sitemap respond as expected and send consistent indexing signals. Use TechSEO Inspector (https://ivig.dev/techseo-inspector/) to inspect an individual page's titles, headings, links and structured data from Chrome. For a broad investigation, use the SEO audit checklist (https://ivig.dev/seo-audit-checklist/) to define the scope. A full review may also need a crawl, Search Console data, internal-link analysis and manual assessment. The tools help collect evidence; deciding what matters still depends on the website and its goals. FAQ ## Sitemap Scout questions Is Sitemap Scout free?+ Yes. The public web app is free and requires no account or installation. Usage limits keep the shared service available: up to 25 URLs across 3 sitemap documents per scan, 5 scans per IP per hour, 20 per IP per day and 150 scans per day overall. Does this tool create or submit a sitemap?+ No. Scout checks a sitemap you already publish. It does not generate an XML file, change your website, or submit URLs to Google. Use your CMS or sitemap generator to make changes, then run a fresh check. Can I check a sitemap index or a large website?+ A scan can cover up to 3 sitemap documents and 25 page URLs. A large sitemap index may exceed that coverage. Check the discovered and checked counts before drawing conclusions. For a full inventory of a large site, use a crawler that supports the required scope. Does a healthy result mean the page is indexed by Google?+ No. Healthy means Scout found no issue in the checks it performed for that request. It does not confirm that Google crawled, indexed or selected the page as canonical. Use Google Search Console URL Inspection to investigate an individual page's indexing status. Why might Scout report a problem when my browser loads the page?+ A browser visit and a server-side request can receive different responses because of a firewall, rate limit, temporary failure or other server behavior. Recheck the URL and inspect the reported HTTP status before changing the page or its sitemap entry. Is the scan processed locally in my browser?+ No. The browser is the interface; the scan uses a server. Full URLs are temporarily stored to perform the check. Query values are hidden in reports, but URL paths and page titles remain visible. Only submit public URLs without credentials or private information. Can I keep or share the results?+ Download the CSV or JSON report before closing the tab. Reports require a private access token and expire after one hour. Expired files are removed on later scan activity; hosting logs and backups may have separate retention. Review exported paths and page titles before sharing them. Free sitemap health check ## See what your sitemap is sending to search engines Open Scout, check a public sitemap and turn the findings into your next fix. If you need help interpreting a result, request a personal first look at your site. Open Sitemap Scout ↗ (https://scout.ivig.dev/)Request a free review (https://ivig.dev/#free-audit) --- ## TechSEO Inspector (Chrome extension landing page) URL: https://ivig.dev/techseo-inspector/ Install: https://chromewebstore.google.com/detail/techseo-inspector/pamgfjigokjaffaeldmgbiimjgjfmppj TechSEO Inspector is a free Chrome extension by Milan Georgijevic (iviG). Click the extension icon on any page and get a 0 to 100 SEO health score in seconds: seven check areas, every result marked pass, warn or fail, with the reason spelled out. No account, about 300 KB, version 1.1.0. ### The seven check areas (weighted scoring) Meta tags (25 points), indexability (20), headings (15), images (15), schema (15), page speed (15), links (10). Failed and warned checks cost points in their area; the weighted total is scaled to a 0 to 100 score. ### Feature highlights - Full report in a side panel: every check area expands into detailed pass / warn / fail results, with a live Google SERP preview inside the meta tags module, a heading tree, an image audit table and a JSON-LD schema viewer. - Page speed graded against Google's thresholds: TTFB, First Contentful Paint, Largest Contentful Paint, layout shift, transfer weight and request count, measured live from the page with the good / needs-improvement bands Google documents for Core Web Vitals. No external speed service. - SERP and social previews: pixel-accurate Google snippet preview, Open Graph and Twitter Card validation, title and description length meters that flag text before it gets truncated. - Snapshots and reporting: save a snapshot before fixes, re-run the audit after, see exactly which checks moved from fail to pass and by how many points. Export as a branded A4 PDF or a paste-ready clipboard summary. - Also included: dark mode, keyboard shortcuts, broken link detection. ### Privacy The analysis runs locally in the browser. No analytics, no tracking, no account system, no server. The only network requests are the ones the audit needs: broken link checks and fetching the robots.txt of the audited site. ### FAQ **Is TechSEO Inspector really free?** Yes. No premium tier, no trial, no account. About 300 KB, everything included. **Does it send browsing data anywhere?** No. Analysis runs locally; the only requests go to the audited site (broken link checks and robots.txt). **Which browsers does it work in?** Built for Chrome, installs from the Chrome Web Store. Chromium-based browsers like Edge, Brave and Opera can generally install it too. **How is the score calculated?** Weighted points per check area (meta tags 25, indexability 20, headings / images / schema / speed 15 each, links 10), scaled to 0-100. **Can reports be exported?** Three ways: branded A4 PDF, paste-ready clipboard summary, and saved snapshots for before/after comparisons. **Does it replace a professional SEO audit?** No. The extension helps with on-page checks, but cannot assess your full site, private Search Console data, server logs or SEO strategy. The free website review is a small initial assessment of public pages. A comprehensive audit is a separate paid service with an agreed scope. --- ## SEO Guides hub URL: https://ivig.dev/seo-guides/ Free, practical SEO guides based on real study data, written by a consultant who implements SEO fixes for a living. No email wall. Current guides: 1. Open Knowledge Format (OKF): What Google's New Spec Means for AEO and GEO - https://ivig.dev/open-knowledge-format/ 2. How to Improve LCP: Find What Delays Your Largest Contentful Paint - https://ivig.dev/improve-lcp-guide/ 3. Noindex Tag: How to Keep Pages Out of Google Without Breaking Your Site - https://ivig.dev/noindex-tag-guide/ 4. JavaScript SEO: How Google Renders JavaScript and How to Test Your Site - https://ivig.dev/javascript-seo-guide/ 5. Image SEO: Alt Text, File Names, Formats and Fast-Loading Images - https://ivig.dev/image-seo-guide/ 6. How to Improve INP: Find and Fix Slow Website Interactions - https://ivig.dev/improve-inp-guide/ 7. Indexed but Not Ranking? How to Find What’s Holding Your Page Back - https://ivig.dev/indexed-but-not-ranking/ 8. Keyword Cannibalization: When Your Pages Compete and When They Don’t - https://ivig.dev/keyword-cannibalization-guide/ 9. Canonical Tag vs. 301 Redirect: Which Should You Use? - https://ivig.dev/canonical-vs-301-redirect/ 10. How to Read Google Search Console: Clicks, Impressions, CTR and Average Position - https://ivig.dev/google-search-console-performance-guide/ 11. Hreflang Explained: International SEO Without the Common Mistakes - https://ivig.dev/hreflang-seo-guide/ 12. Duplicate Content and SEO: When It Matters and How to Fix It - https://ivig.dev/duplicate-content-seo-guide/ 13. What Is Technical SEO? A Beginner's Guide to How Your Website Gets Found - https://ivig.dev/technical-seo-guide/ 14. SEO Audit Checklist: How to Audit a Website Step by Step - https://ivig.dev/seo-audit-checklist/ 15. Keyword Research for Beginners: How to Find Topics Worth Targeting - https://ivig.dev/keyword-research-guide/ 16. Search Intent Explained: How to Create Content People Actually Want - https://ivig.dev/search-intent-guide/ 17. Internal Linking for SEO: How to Build Links That Help Google and Users - https://ivig.dev/internal-linking-seo-guide/ 18. Canonical URLs Explained: What They Are and How to Use Them - https://ivig.dev/canonical-url-guide/ 19. How Google Search Works: Crawling, Indexing and Ranking Explained - https://ivig.dev/how-google-search-works/ 20. Schema Markup Explained: What It Does for SEO and How to Add It - https://ivig.dev/schema-markup-guide/ 21. Core Web Vitals Explained: How to Read, Diagnose and Fix LCP, INP and CLS - https://ivig.dev/core-web-vitals-guide/ 22. How to Set Up Google Analytics 4 (and the Five Settings Everyone Misses) - https://ivig.dev/ga4-setup-guide/ 23. HTTP Status Codes Explained: What 200, 301, 404, 410 and 5xx Mean for SEO - https://ivig.dev/http-status-codes-guide/ 24. Robots.txt Explained: What to Block, What Not To, and Why - https://ivig.dev/robots-txt-guide/ 25. Sitemap.xml: Why It Matters and How to Get It Right - https://ivig.dev/xml-sitemap-guide/ 26. Why Is My Page Not Indexed in Google? How to Find and Fix It - https://ivig.dev/page-not-indexed/ 27. Google Search Console Setup: The Complete Walkthrough - https://ivig.dev/google-search-console-setup/ 28. SEO Meta Tags: The Free On-Page SEO Guide - https://ivig.dev/on-page-seo-guide/ --- ## Guide: Open Knowledge Format (OKF): What Google's New Spec Means for AEO and GEO URL: https://ivig.dev/open-knowledge-format/ Author: Milan Georgijevic Published: October 16, 2026 OKF is a real, useful format from Google Cloud for giving AI agents curated knowledge as Markdown files. It isn't a Google Search ranking factor, and no AI search engine has said it reads it. Here's what it is, an example bundle, and when it's worth your time. **The Open Knowledge Format (OKF) is an open specification from Google Cloud for packaging knowledge as a folder of Markdown files with YAML frontmatter, so AI agents and people can read and maintain it.** It was built for organizational knowledge, such as data tables, metrics and runbooks, rather than for search engines. This guide explains the format from the specification itself, separates it from the AEO and GEO claims attached to it, and covers when publishing a bundle makes sense. All details were checked against the spec in Google's repository in October 2026. ### What OKF Is The Open Knowledge Format is a way to package knowledge as a folder of Markdown files. Each file describes one concept, starts with a short YAML block of metadata and links to related files with ordinary Markdown links. The links turn the folder into a graph that a person or an AI agent can browse one file at a time. It came from Google Cloud's data analytics and BigQuery engineers, not from Google Search. [Google Cloud's announcement](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing), published June 12, 2026, describes the problem it targets: the knowledge agents need inside a company, such as what a table contains, what a metric means or how to handle an incident, is scattered across catalogs, wikis, drives and people's heads. The post presents OKF as a format rather than a service: no new runtime and no required SDK. - **v0.2** the current specification version in Google's GitHub repository, superseding the v0.1 release (Source: [OKF on GitHub](https://github.com/GoogleCloudPlatform/open-knowledge-format)) - **1** required field per concept: `type`. A file with only that line is fully conformant (Source: [OKF v0.2 spec](https://github.com/GoogleCloudPlatform/open-knowledge-format/blob/main/SPEC.md)) - **0** mentions of Google Search, SEO or AI Overviews in the announcement (Source: [Google Cloud Blog](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing)) The repository is licensed under Apache 2.0. Alongside the spec, it holds a proof-of-concept agent that writes OKF documents from BigQuery metadata and documentation pages, a viewer that renders a bundle as an interactive graph in a single HTML file, and sample bundles for the public GA4 e-commerce, Stack Overflow and Bitcoin datasets. ### What an OKF Bundle Looks Like A collection of OKF files is called a knowledge bundle. You organize the folders however suits the subject. The spec reserves only two file names: `index.md`, which lists a folder's contents so an agent can see what's there before opening anything, and `log.md`, a dated change history. Every other `.md` file is a concept. Here's a small bundle for a fictional software company's help content. It isn't a real product; it's sized so you can read the whole thing. A bundle is just a folder of Markdown files ~~~ acme-help/ index.md # optional: lists what's in this folder log.md # optional: dated history of changes products/ index.md starter-plan.md # one concept per file pro-plan.md policies/ index.md refund-policy.md guides/ index.md connect-your-domain.md ~~~ Each concept file has frontmatter and a body. This one uses the optional v0.2 trust fields to record who wrote it, who confirmed it and when it should be checked again. Markdown: policies/refund-policy.md ~~~ --- type: Policy title: Refund policy description: Who can get a refund, within how many days, and how to ask for one. resource: https://acme.example/legal/refunds/ tags: [billing, refunds] status: stable generated: { by: human:jsmith, at: 2026-10-01T09:00:00Z } verified: { by: human:finance-lead, at: 2026-10-02T15:30:00Z } stale_after: 2027-04-01T00:00:00Z --- # Summary Monthly plans can be refunded within 14 days of the first payment. Annual plans are refunded pro rata. Usage add-ons aren't refundable. # How to request Customers email billing@acme.example from the account owner's address. Plan details live in [Starter plan](/products/starter-plan.md) and [Pro plan](/products/pro-plan.md). ~~~ The links in the body use paths that start with `/`, which the spec recommends because they're relative to the bundle root and survive moving files between folders. Broken links are allowed; the spec treats them as knowledge that hasn't been written yet. Frontmatter fields in OKF v0.2 | Field | Status | What it's for | | --- | --- | --- | | `type` | Required | The kind of concept, such as `Metric`, `API Endpoint` or `Policy`. There's no official list; you choose the values. | | `title`, `description` | Recommended | A display name and a one-sentence summary used in indexes and previews. | | `resource` | Recommended | A URI for the real thing the concept describes, such as a table, an API or a web page. | | `tags` | Recommended | Short labels for cross-cutting groups. | | `sources` | Optional (v0.2) | Where the content came from, with signals such as author and last change. | | `generated`, `verified` | Optional (v0.2) | Who or what wrote the concept and who confirmed it. A `human:` verifier makes it human-reviewed. | | `status`, `stale_after` | Optional (v0.2) | Draft, stable or deprecated, plus a date after which the content should be treated as stale. | If you've read older coverage, note one change. Version 0.1 listed an optional `timestamp` field and a `Citations` section in the body. The [OKF v0.2 specification](https://github.com/GoogleCloudPlatform/open-knowledge-format/blob/main/SPEC.md) replaces them with `generated.at` and the `sources` list. It also adds an `Attested Computation` concept type for data teams that need proof a number was calculated the approved way, which few website owners will need. The index file at the bundle root is the only index allowed to carry frontmatter, and only to declare the version: Markdown: index.md at the bundle root ~~~ --- okf_version: "0.2" --- # Products * [Starter plan](products/starter-plan.md) - Single-site plan with email support. * [Pro plan](products/pro-plan.md) - Multi-site plan with priority support. # Policies * [Refund policy](policies/refund-policy.md) - Who can get a refund and how to ask. # Guides * [Connect your domain](guides/connect-your-domain.md) - DNS records and how to check them. ~~~ Markdown: log.md ~~~ # Directory Update Log ## 2026-10-02 * **Update**: Refund window confirmed by finance in [Refund policy](/policies/refund-policy.md). ## 2026-10-01 * **Initialization**: Created products, policies and guides. ~~~ ### What OKF Isn't Several SEO blogs present OKF as a new answer engine optimization (AEO) or generative engine optimization (GEO) tactic. The primary sources don't support that, at least not yet. **What the sources support** - An open, vendor-neutral file format for AI agents and people - Aimed mainly at organizational and data knowledge - Readable with any text editor and storable in Git - An early specification still at version 0.x **What they don't support** - A Google Search ranking factor - A way to get into AI Overviews or AI Mode - Proof that AI search engines fetch OKF bundles - A replacement for schema.org structured data Google Search's own position on AI features is direct. [Google Search's AI features documentation](https://developers.google.com/search/docs/appearance/ai-features) says you don't need new machine-readable files, AI text files or markup to appear in AI Overviews or AI Mode. Pages need to be indexed and eligible for a snippet. That statement covers llms.txt-style files in general; it doesn't single out OKF, but nothing from Google suggests an exception. I haven't found a primary source from OpenAI, Anthropic, Perplexity or Microsoft saying their search products read OKF bundles. If one appears, it changes the advice. Until then, treat claims that OKF will raise your AI visibility as speculation. ### OKF vs llms.txt, Schema Markup and Markdown Pages OKF lands in a crowded space of formats for machine readers. They're easy to mix up, but they answer different questions. OKF, llms.txt, schema markup and Markdown pages compared | Format | Built for | Where it lives | Read by Google Search? | | --- | --- | --- | --- | | Schema.org structured data | Search engines understanding page content and rich results. | Inside your HTML pages. | Yes, documented for rich results. | | llms.txt | LLMs and agents reading a website at inference time. | `/llms.txt` at the site root. | Not required for AI features, per Google. | | Markdown page versions | Agents that prefer clean text over HTML. | Next to each page, such as `page.md`. | No documented use. | | OKF bundle | Agents and people sharing curated organizational knowledge. | A Git repo, archive or folder. | No documented use. | **Schema markup** describes the content of a page to search engines and is the only one here with documented search features attached. Our [schema markup guide](https://ivig.dev/schema-markup-guide/) covers it. **llms.txt** is a proposal by Jeremy Howard, published at [llmstxt.org](https://llmstxt.org/) in September 2024: a Markdown file at the site root that summarizes the site and links to its key pages. The same proposal suggests offering clean Markdown versions of pages at the same URL with `.md` added. This site ships an [llms.txt](https://ivig.dev/llms.txt) and a longer [llms-full.txt](https://ivig.dev/llms-full.txt) with the text of every guide, but not per-page Markdown files. **OKF** overlaps most with llms.txt, since both are Markdown for agents. The difference is scope. llms.txt is a single entry point to a public website. OKF is a whole graph of small, typed documents with provenance and freshness built in, designed to be maintained over time by people and agents together, usually inside an organization. ### Should You Publish an OKF Bundle? For most websites, not yet. It depends on what you expect it to do. Interactive tool: https://ivig.dev/open-knowledge-format/#decide (a one-question picker, "What do you want OKF to do for you?", that recommends the right approach): - Work on indexable, useful pages: Google says AI features need no special files. Pages must be indexed and eligible for a snippet. Start with [technical SEO basics](https://ivig.dev/technical-seo-guide/) and [search intent](https://ivig.dev/search-intent-guide/). - Make your public pages easy to read and quote: No AI search provider has documented reading OKF bundles. Crawlable HTML, clear answers and an allowed crawler in [robots.txt](https://ivig.dev/robots-txt-guide/) matter more. An llms.txt file is cheap to add but optional. - Publish an OKF bundle next to your docs: If your docs already live as Markdown in Git, adding `type` frontmatter and index files costs little. Generate it from the same source as the site so the two can't drift apart. - Start with your most-questioned data: This is what Google built it for: table meanings, metric definitions, runbooks. Start with a handful of concepts your team keeps explaining and record who verified each one. The case is strongest where your content is already structured knowledge: developer documentation, API references, product specifications or data dictionaries, especially if they already live as Markdown files in Git. Adding frontmatter and index files there is a few hours of work, and an agent given the bundle gets well-scoped files instead of scraped HTML. The case is weakest for a marketing site or a blog hoping for traffic. You'd be maintaining a second copy of your content for readers that, as far as anyone has documented, don't request it. ### What to Do for AEO and GEO Instead Answer engines and AI search features still mostly find content the way search engines do: by crawling public pages. The basics carry over. - **Make sure important pages are indexable.** No accidental noindex, no blocked resources, correct canonicals. The [noindex guide](https://ivig.dev/noindex-tag-guide/) and [page not indexed guide](https://ivig.dev/page-not-indexed/) cover the common traps. - **Put the answer in the HTML.** Content that appears only after JavaScript runs is harder for every crawler. See the [JavaScript SEO guide](https://ivig.dev/javascript-seo-guide/). - **Write pages that answer one need clearly.** Specific headings, direct answers near the top and real data are easier to quote. The [search intent guide](https://ivig.dev/search-intent-guide/) helps decide what a page should cover. - **Decide which AI crawlers you allow.** The [robots.txt guide](https://ivig.dev/robots-txt-guide/) explains the user agent tokens and the trade-offs. - **Add llms.txt if it's cheap for you.** It's a small file that's easy to generate, but treat it as optional, not a ranking lever. **If you do build a bundle, generate it.** A hand-maintained copy of your content will drift from the live pages within months. Produce the OKF files from the same source as your site or docs, set `resource` to the live URL of each page and use `stale_after` so stale concepts are flagged automatically. Keep an eye on the spec. It moved from 0.1 to 0.2 within months, with two breaking changes. Anything built on it today should be easy to regenerate when it changes again. ### Frequently Asked Questions **Is the Open Knowledge Format a Google Search ranking factor?+** No. OKF comes from Google Cloud's data analytics team, and the announcement doesn't mention Search. Google Search says no special AI files are needed to appear in AI Overviews or AI Mode. **Do ChatGPT, Perplexity or Google AI Overviews read OKF files?+** No provider has documented it. OKF bundles are designed to be given to agents, for example from a Git repository, rather than discovered by crawlers on public websites. **What is the difference between OKF and llms.txt?+** llms.txt is a single Markdown file at a website's root that summarizes the site for language models. OKF is a folder of many typed Markdown documents linked into a graph, with optional fields for provenance and freshness. **What fields does an OKF document need?+** Only type is required. Title, description, resource and tags are recommended, and version 0.2 adds optional fields for sources, who generated and verified a concept, its status and when it goes stale. **Should my website publish an OKF bundle?+** Only if you have structured knowledge such as developer docs or data definitions that agents will be given directly. For search traffic, indexable and useful pages matter far more. ### Related Guides - [Add structured data search engines do use](https://ivig.dev/schema-markup-guide/). - [Understand how Google finds and ranks pages](https://ivig.dev/how-google-search-works/). - [Control which AI crawlers can access your site](https://ivig.dev/robots-txt-guide/). - [Keep content readable without JavaScript](https://ivig.dev/javascript-seo-guide/). --- ## Guide: How to Improve LCP: Find What Delays Your Largest Contentful Paint URL: https://ivig.dev/improve-lcp-guide/ Author: Milan Georgijevic Published: October 4, 2026 Most slow LCP scores aren't caused by a heavy image download. They're caused by waiting: for the server, for a script to reveal the image, or for the browser to decide the image matters. Measure which wait you have before changing anything. **To improve LCP, find the largest element in the first screen, split its loading time into four phases, and fix the biggest phase first.** A server problem needs a server fix; an image hidden behind JavaScript needs a markup fix. Compressing images helps only one of the four. This guide is for site owners and developers looking at a poor or borderline LCP in PageSpeed Insights or Search Console. For INP and CLS, and for how Google uses these metrics, read the [Core Web Vitals guide](https://ivig.dev/core-web-vitals-guide/) first. ### What LCP Measures Largest Contentful Paint reports when the largest image, video poster or text block visible in the viewport finished rendering, measured from the moment the visitor started loading the page. It's a loading metric. It doesn't say when the page became usable or when every image arrived, only when the biggest piece of visible content appeared. A good LCP is **2.5 seconds or less**; anything above 4 seconds is poor. Google assesses the 75th percentile of page loads, split by mobile and desktop, so a fast result on your office connection says little about the slowest quarter of real visits. Thresholds, eligible element types and the elements browsers ignore (invisible elements, full-viewport backgrounds and low-detail placeholder images) are listed in [Google's LCP documentation](https://web.dev/articles/lcp). - **59%** of mobile websites had a good LCP in 2024, against 72% on desktop (Source: [Web Almanac 2024](https://almanac.httparchive.org/en/2024/performance)) - **73%** of mobile pages have an image as their LCP element. Text accounts for most of the rest (Source: [Web Almanac 2024](https://almanac.httparchive.org/en/2024/performance)) - **35%** of mobile pages have an LCP element the browser can't find in the initial HTML (Source: [Web Almanac 2024](https://almanac.httparchive.org/en/2024/performance)) Those last two numbers explain where most of this guide goes. On a typical page the LCP element is an image, and on a third of mobile pages that image only becomes visible to the browser after CSS or JavaScript runs. That's a delay you can usually remove without touching the server. ### Find Your LCP Element First Don't start by compressing every image on the site. Identify the specific element that's being measured on the template that's slow. A product page, a blog post and the homepage often have different LCP elements and different problems. 1. Run the URL through [PageSpeed Insights](https://pagespeed.web.dev/). The top section shows field data from real Chrome users when enough exists; the lab section below it is one simulated load. 2. In the lab diagnostics, find the Largest Contentful Paint element. It names the node, such as a hero `img` or a heading. 3. Open the page in Chrome, then DevTools, then **Performance**. Record a page load with the throttling you'll keep for later comparisons. 4. Open the **LCP breakdown** insight. Chrome splits the time into four phases, which the next section explains. 5. Repeat on a mobile viewport. The LCP element on a phone is often a different element from the desktop one, especially when the hero image is hidden or cropped on small screens. Chrome's documentation for the [LCP breakdown insight](https://developer.chrome.com/docs/performance/insights/lcp-breakdown) describes the panel. If PageSpeed Insights shows no field data, the URL doesn't have enough Chrome traffic for the report. That's not evidence that it's fast or slow; rely on lab tests and your own measurement until it does. ### Break LCP Into Four Phases Every image LCP can be split into the same four parts. Finding the largest one tells you which kind of fix to try. [Google's LCP optimization guide](https://web.dev/articles/optimize-lcp) defines them and suggests a rough budget for each. The four LCP phases and where the time should go | Phase | What it covers | Rough target share | | --- | --- | --- | | Time to First Byte | From starting the navigation to receiving the first byte of HTML. | About 40% | | Resource load delay | From the first byte to the moment the browser starts downloading the LCP image. | Under 10% | | Resource load duration | Downloading the LCP image itself. | About 40% | | Element render delay | From the image finishing to it actually appearing on screen. | Under 10% | Text LCP elements have no resource to download, so their time is TTFB plus render delay. Web fonts, hidden content and render-blocking files tend to dominate there. **Even fast sites spend most of their LCP waiting**: Median p75 LCP phases for origins with a good LCP, July 2024 (milliseconds) - TTFB (server response): 600 ms - Load delay (before the image starts): 350 ms - Load duration (downloading the image): 160 ms - Render delay (before it appears): 230 ms Source: [Web Almanac 2024](https://almanac.httparchive.org/en/2024/performance) performance chapter, CrUX data. The image download is the smallest phase; the waiting around it is larger. The chart is the useful surprise. Teams often go straight to image compression, yet across sites with good LCP, downloading the image was the shortest phase. The server response and the delay before the browser even requests the image took far longer. ### Fix a Slow Server Response If TTFB is the largest phase, image work won't fix it. Look at what happens before the HTML leaves the server. - **Redirects before the page.** An ad link that goes from http to https to www to the final URL adds a full round trip for each hop. Link to the final URL. Our [HTTP status codes guide](https://ivig.dev/http-status-codes-guide/) explains how to trace a chain. - **Uncached HTML.** On WordPress and similar systems, a page cache can serve stored HTML instead of rebuilding it from the database on every visit. Check that it's active for logged-out visitors and isn't bypassed by a cookie or query string. - **Distance.** A CDN that caches HTML close to visitors helps an audience spread across countries. Caching only images and CSS on the CDN leaves the HTML trip unchanged. - **Slow back-end work.** Personalization, API calls or heavy plugins that run before the response. Profile them on the server; the browser can only show you the wait. Test TTFB from more than one location and repeat requests. The first uncached request after a deployment is often much slower than what most visitors receive, and both numbers matter. ### Remove the Delay Before the Image Starts This is the phase with the most room for quick wins. The goal from Google's guidance is simple: the LCP image should start downloading at about the same time as the first resources the page requests. Three patterns usually prevent that. **The image isn't in the HTML.** When a slider script, a JavaScript framework or a CSS `background-image` supplies the hero image, the browser can't see it until those files arrive and run. Use a normal `img` element with a real `src` in the server's HTML wherever possible. If the design truly needs a CSS background, preload it. **The image is lazy-loaded.** `loading="lazy"` tells the browser to wait until it knows the image is near the viewport, which requires layout first. That's right for images further down the page and always wrong for the LCP image. In 2024, 9.5% of mobile pages still natively lazy-loaded their LCP image, and another 6.7% did it with a script, according to the [Web Almanac 2024](https://almanac.httparchive.org/en/2024/performance). Plugins and themes that lazy-load every image are the usual cause. **The image has normal priority.** Browsers usually start images at low priority and raise it once layout confirms the image is visible. `fetchpriority="high"` gives the browser that information upfront. On the Google Flights homepage, adding it to the hero image improved LCP from 2.6 to 1.9 seconds, as documented in [web.dev's Fetch Priority article](https://web.dev/articles/fetch-priority). It's a hint, so use it on one or two images, not every image on the page. HTML: before and after for a hero image ~~~
Technician replacing a laptop screen at a repair bench ~~~ A preload for a responsive image also needs `imagesrcset` and `imagesizes` attributes to match the image you actually serve, or the browser can download the wrong file. When you can switch to an `img` element, that's the simpler fix. **Check the mobile hero separately.** Some themes show a different, portrait-cropped image on phones through CSS. The desktop image gets the priority hint while the mobile LCP image stays hidden in a stylesheet. Use a `picture` element with media conditions instead, so the browser picks the right file from the HTML. ### Shorten the Image Download Once the request starts early, make the file smaller. A 1,600-pixel-wide image squeezed into a 390-pixel phone layout wastes most of its bytes. - Serve sizes that match the layout with `srcset` and an accurate `sizes` value. - Use WebP or AVIF where your image pipeline supports it, with sensible compression. Compare the result visually; an artifact-ridden hero image isn't a win. - Serve the image from your own origin or a CDN connection the page already uses. A new third-party domain adds connection setup before the download can begin. - Set long cache lifetimes for versioned image URLs so repeat visits don't download it again. Formats, responsive markup and alt text are covered in more depth in the [image SEO guide](https://ivig.dev/image-seo-guide/). ### Cut the Render Delay If the image has downloaded but still isn't on screen, something is holding up rendering. - **Render-blocking CSS and scripts.** Large stylesheets and synchronous scripts in the `head` must finish before the first render. Google's guidance is to keep render-blocking CSS smaller than the LCP resource itself; inline the small amount of CSS needed for the first screen and defer the rest where your build allows it. - **Content hidden until JavaScript runs.** Client-side rendered pages, sliders that fade in and A/B testing snippets that hide the page until an experiment loads all add render delay. The [JavaScript SEO guide](https://ivig.dev/javascript-seo-guide/) covers rendering approaches that put content in the initial HTML. - **Web fonts for text LCP.** If a heading is the LCP element and its font loads late, the text may stay invisible. Preload the one font file used above the fold and use a `font-display` value that shows fallback text. - **Long main-thread tasks.** Heavy scripts can delay painting even when everything has arrived. The same tools that diagnose slow interactions help here; see the [INP guide](https://ivig.dev/improve-inp-guide/). ### Verify the Fix Without Overclaiming Compare before and after in the lab with the same URL, device emulation, throttling and cache state. Check that the LCP element is still the one you optimized; making the hero faster can make a heading the new LCP element, which is fine, but it changes what you're measuring. Field data changes more slowly. CrUX data is a 28-day rolling average, so PageSpeed Insights won't reflect the full effect of a release for about four weeks, according to the [CrUX API documentation](https://developer.chrome.com/docs/crux/api). Note the release date and judge the trend after that window, not the day after deployment. **LCP release checklist** - The LCP element is identified for mobile and desktop on each affected template - The largest of the four phases is known before choosing a fix - The LCP image is an `img` with a real `src` in the server HTML - The LCP image isn't lazy-loaded and carries `fetchpriority="high"` - Image files match their displayed size and use an efficient format - Redirects before the page are removed and HTML caching works for visitors - Lab results are compared under identical settings - Field data is reviewed after the 28-day window Faster LCP is good for visitors, but it isn't a ranking guarantee. Core Web Vitals are one signal among many. If the page is fast and still invisible in search, the cause is elsewhere; start with the [Core Web Vitals guide](https://ivig.dev/core-web-vitals-guide/) for the wider picture and the [indexed-but-not-ranking checklist](https://ivig.dev/indexed-but-not-ranking/) for visibility problems. ### Frequently Asked Questions **What is a good LCP score?+** Google considers 2.5 seconds or less good and anything over 4 seconds poor, assessed at the 75th percentile of page loads for mobile and desktop separately. **Should I lazy-load my hero image?+** No. Lazy loading makes the browser wait for layout before requesting the image, which adds delay to the LCP. Keep lazy loading for images further down the page. **Does fetchpriority high work on every browser?+** Current versions of Chrome, Edge, Firefox and Safari support it. Browsers that ignore it load the image normally, so adding it to the LCP image is low risk. **Why is my PageSpeed Insights lab LCP different from the field data?+** The lab result is one simulated load on fixed settings. Field data reflects real visits over the previous 28 days on many devices and connections. Use the lab to diagnose and the field data to judge the outcome. **Will improving LCP raise my rankings?+** Not necessarily. Page experience is one of many signals, and relevance matters far more. Improve LCP because slow pages lose visitors, and treat any ranking change as a bonus, not a promise. ### Related Guides - [Understand all three Core Web Vitals](https://ivig.dev/core-web-vitals-guide/). - [Find and fix slow interactions](https://ivig.dev/improve-inp-guide/). - [Optimize images for search and speed](https://ivig.dev/image-seo-guide/). - [Check what JavaScript hides from the first render](https://ivig.dev/javascript-seo-guide/). --- ## Guide: Noindex Tag: How to Keep Pages Out of Google Without Breaking Your Site URL: https://ivig.dev/noindex-tag-guide/ Author: Milan Georgijevic Published: October 4, 2026 Noindex is the cleanest way to keep a live page out of Google. It's also one of the easiest ways to wipe a site from search by accident. Here's how to use it on purpose and how to catch it when it's wrong. **A noindex tag keeps a page out of Google's search results, but only if Google is allowed to crawl the page and read it.** That one condition explains most noindex problems: pages that won't leave the index because robots.txt hides the tag, and pages that vanish because a forgotten setting added it. This guide covers the meta tag and the HTTP header, how noindex compares with robots.txt, canonicals and deletion, and how to check any page. For a refresher on the other meta tags, see the [on-page SEO meta tags guide](https://ivig.dev/on-page-seo-guide/). ### What Noindex Does and Doesn't Do A noindex rule tells search engines not to show a page in their results. Google has to crawl the page to read the rule. After it does, the page drops out of results even if other sites link to it. Noindex doesn't block crawling, hide the page from visitors or protect private information. Anyone with the URL can still open it. It also takes effect only when Google next crawls the page, which for a rarely visited URL can take months, as [Google's noindex documentation](https://developers.google.com/search/docs/crawling-indexing/block-indexing) warns. 1. **Crawl allowed**: Robots.txt lets Googlebot fetch the page, so it can read the HTML and headers. (Fails here: a robots.txt Disallow hides the rule) 2. **Rule found**: Google sees noindex in a meta tag or an X-Robots-Tag header on the response. (Fails here: the tag is added or removed only by JavaScript) 3. **Dropped from results**: The page stops appearing in Google Search after it's processed. (Slow here: rarely crawled pages can take months) - **3.9%** of mobile pages carried a noindex rule in their rendered robots directives in 2024 (Source: [Web Almanac 2024](https://almanac.httparchive.org/en/2024/seo)) - **2019** Google stopped supporting noindex lines in robots.txt on September 1, 2019 (Source: [Google Search Central](https://developers.google.com/search/blog/2019/07/a-note-on-unsupported-rules-in-robotstxt)) - **~6 mo** how long a temporary removal in Search Console lasts. Noindex is the lasting fix (Source: [Search Console Help](https://support.google.com/webmasters/answer/9689846)) ### Two Ways to Add Noindex **The robots meta tag** goes in the `head` of an HTML page. It's the right choice for most pages, and most CMS platforms and SEO plugins add it for you with a checkbox. HTML: inside the head ~~~ ~~~ **The X-Robots-Tag HTTP header** is sent by the server with the response. Use it for files that have no HTML `head`, such as PDFs, or to apply a rule to many URLs at once from server configuration. Apache (.htaccess): noindex every PDF ~~~ Header set X-Robots-Tag "noindex" ~~~ Nginx: noindex every PDF ~~~ location ~* \.pdf$ { add_header X-Robots-Tag "noindex"; } ~~~ The Apache example needs `mod_headers`, which most hosts enable. The rule names and the header aren't case-sensitive. If several rules conflict, Google applies the most restrictive one. Both points come from the [robots meta tag specification](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag), which also lists the other rules such as `nosnippet` and `noimageindex`. You don't need `index` or `follow` values. Indexing and following links are the default, so `content="index, follow"` does nothing. It isn't harmful, but it shouldn't be what you check when a page is missing from Google. ### Noindex, Robots.txt, Canonical or Delete? Noindex is one of several tools that look similar from the outside. Picking the wrong one is the most common mistake I see, so start with what you actually want to happen. Choose the tool by the outcome you need | Goal | Use | Why not noindex? | | --- | --- | --- | | Keep a page live for visitors but out of Google | Noindex, with crawling allowed | This is exactly what noindex is for. | | Stop crawlers wasting time on endless filter or search URLs | Robots.txt Disallow | Noindex pages still get crawled. Disallow stops the fetching, but a blocked URL can still be indexed from links without its content. | | Several URLs show the same content and one should rank | Canonical tag or redirect | Noindex removes a URL without passing its role to the preferred version. | | The page is gone for good | 404 or 410 status | A deleted page should say so. There is nothing left to keep live. | | The content is private | Password or login | Noindex pages are public to anyone with the URL. | The robots.txt row causes most of the confusion. If you disallow a page in robots.txt, Google never fetches it, so it never sees the noindex tag. The URL can then appear in results with no description, because links elsewhere told Google it exists. Our [robots.txt guide](https://ivig.dev/robots-txt-guide/) covers what the file is good for, and the [canonical URL guide](https://ivig.dev/canonical-url-guide/) covers duplicate versions. Not sure which applies? Answer one question. Interactive tool: https://ivig.dev/noindex-tag-guide/#choose (a one-question picker, "What should happen to the page?", that recommends the right tool): - Noindex, with crawling allowed: Add a robots meta tag or X-Robots-Tag header and check that robots.txt doesn't block the URL. Then confirm the rule in URL Inspection. - A narrow robots.txt Disallow rule: Good for crawl traps like faceted filters and internal search. Remember a blocked URL can still be indexed from links. If it must leave results, use noindex first and block only after it has dropped out. - A canonical tag or a 301 redirect: Use a redirect when visitors should land on the other URL, a canonical when both versions must stay available. See [canonical vs. 301 redirect](https://ivig.dev/canonical-vs-301-redirect/). - A 404 or 410 status code: Remove the page and return a real error status, or redirect to a close replacement if one exists. Use the Removals tool only for urgent, temporary hiding. - Authentication: Put the content behind a login or HTTP authentication. A noindex tag or robots.txt line doesn't stop anyone from opening a URL they have. ### When Noindex Is the Right Call **Good noindex candidates** - Internal site search result pages - Thank-you and order confirmation pages - Thin tag or author archives you can't improve or remove yet - Printer-friendly or downloadable copies of pages you've already published - Campaign landing pages meant only for paid or email traffic **Poor noindex candidates** - Product variants that should consolidate to one URL - Pages you just want ranking better - Staging sites (use a password) - Pages blocked in robots.txt - Every page that shares a keyword with another A useful test: would you be comfortable if Google never showed this page to anyone, while visitors who reach it from your menu or an email still get value? If yes, noindex fits. If you're hoping the page will rank later, fix it instead. The [duplicate content guide](https://ivig.dev/duplicate-content-seo-guide/) and the [keyword cannibalization guide](https://ivig.dev/keyword-cannibalization-guide/) help when the real issue is overlap. ### Mistakes That Remove the Wrong Pages **The staging setting goes live.** Many sites are built with a "discourage search engines" option switched on, which adds a sitewide noindex. When the site launches, nobody switches it off. The symptom is a site that never appears in Google, or one that drops out after a redesign. Check the CMS setting and the live HTML after every launch. **Noindex and Disallow together.** Blocking the page in robots.txt hides the noindex. If a page has to leave results, keep it crawlable until it's gone. Only then decide whether a Disallow is worth adding. **JavaScript removes the tag.** Some apps ship `noindex` in the initial HTML and remove it once the page loads. Google's [JavaScript SEO basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) say Google may skip rendering when it sees noindex, so the removal may never run. A [Vercel and MERJ study of over 100,000 Googlebot fetches](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process) in April 2024 found pages with noindex in the initial HTML weren't rendered at all. Put the final robots rule in the server response. **A header nobody can see.** An X-Robots-Tag set in a server config, CDN rule or security plugin doesn't show up in the page source. If a page is noindexed and the HTML looks clean, check the response headers. **Noindexed pages in the XML sitemap.** A sitemap tells Google these are URLs you want indexed; the noindex says the opposite. Remove noindexed URLs from the sitemap. Our free [Sitemap Scout](https://ivig.dev/sitemap-scout/) flags noindex pages in a sitemap, and the [XML sitemap guide](https://ivig.dev/xml-sitemap-guide/) explains what belongs there. **A plugin template noindexes a whole section.** One wrong setting for categories, products or paginated pages can affect thousands of URLs. Spot-check one URL from each template after changing SEO plugin settings. ### How to Check a Page for Noindex 1. **Look at the page source.** Press Ctrl+U (Cmd+Option+U on Mac) and search for `noindex`. This shows the server's HTML, not what JavaScript changes later. 2. **Check the response headers.** In DevTools, open **Network**, reload, select the document request and read the response headers. Or use the command below. 3. **Run URL Inspection in Search Console.** The live test reports whether indexing is allowed and which rule Google found. The [Search Console setup guide](https://ivig.dev/google-search-console-setup/) helps if you don't have access yet. 4. **Review the Page indexing report.** URLs Google dropped because of the rule are listed under **Excluded by 'noindex' tag**. Scan the list for pages that should be indexed. Terminal: check the headers and HTML for robots rules ~~~ curl -sI https://example.com/page/ | grep -i x-robots-tag curl -s https://example.com/page/ | grep -io ']*robots[^>]*>' ~~~ Both commands print nothing if no rule is present. Some servers send a different response to command-line tools, so confirm a surprising result with URL Inspection. For a quick per-page check while browsing, the free [TechSEO Inspector](https://ivig.dev/techseo-inspector/) extension shows the page's indexability status. ### Removing Noindex and Getting the Page Back Delete the meta tag or header at its source, whether that's the template, plugin setting, CMS toggle or server rule. Confirm the live page is clean with the checks above, then request indexing in URL Inspection. If many URLs were affected, fix the template, keep them in the XML sitemap and use **Validate fix** in the Page indexing report. Validation typically takes up to about two weeks, according to [Google's Page indexing report help](https://support.google.com/webmasters/answer/7440203), though it can take longer. Returning to the index doesn't guarantee returning to the old positions straight away. If the page is back in the index but gets little traffic, work through the [indexed-but-not-ranking checklist](https://ivig.dev/indexed-but-not-ranking/). If it still isn't indexed after the rule is gone, the [page not indexed guide](https://ivig.dev/page-not-indexed/) covers the other causes. ### Frequently Asked Questions **Does noindex stop Google from crawling a page?+** No. Google has to keep crawling a page to see its noindex rule. To stop crawling, use robots.txt, but not on a page you also need removed from results. **Can I put noindex in robots.txt?+** No. Google stopped supporting noindex lines in robots.txt on September 1, 2019. Use a robots meta tag or an X-Robots-Tag header instead. **How long does noindex take to remove a page from Google?+** It takes effect when Google next crawls and processes the page. That can be days for popular pages and months for rarely crawled ones. Requesting indexing in URL Inspection can speed up the recrawl. **Should I use noindex, follow?+** You can, but follow is the default, so noindex on its own does the same job. Links on a noindexed page can still be discovered when Google crawls it. **Is noindex bad for SEO?+** Not when it's deliberate. Keeping low-value pages like internal search results out of the index is normal. It's harmful only when it lands on pages you want found. ### Related Guides - [Use robots.txt for crawl control](https://ivig.dev/robots-txt-guide/). - [Find why a page isn't indexed](https://ivig.dev/page-not-indexed/). - [Handle duplicate URLs with canonicals](https://ivig.dev/canonical-url-guide/). - [Keep robots rules out of JavaScript](https://ivig.dev/javascript-seo-guide/). --- ## Guide: JavaScript SEO: How Google Renders JavaScript and How to Test Your Site URL: https://ivig.dev/javascript-seo-guide/ Author: Milan Georgijevic Published: October 4, 2026 Google renders JavaScript. That doesn't mean everything your scripts do reaches the index. Links without URLs, content behind clicks and error pages that return 200 still get lost. Here's how to find them. **JavaScript SEO means making sure search engines can find, render and index content that your scripts create.** Google runs JavaScript in a headless version of Chromium, but it doesn't click, scroll or wait forever, and it acts on some signals before rendering at all. This guide is for site owners with a React, Vue, Angular or similar site, and for developers asked why pages aren't showing up. It assumes you know the basics of crawling and indexing; if not, start with [how Google Search works](https://ivig.dev/how-google-search-works/). ### How Google Processes JavaScript Pages Google handles a JavaScript page in three phases: it crawls the URL and reads the HTML the server returns, renders the page in a headless version of Chromium to run the JavaScript, then indexes the rendered result. [Google's JavaScript SEO basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) describe the process. The important detail is the gap between the first and second phases. Pages wait in a render queue, which Google says can take a few seconds or longer. 1. **Crawl**: Googlebot fetches the URL and reads the server's HTML, including links, status code and robots rules. (Stops here: robots.txt blocks, error status, noindex in the HTML) 2. **Render**: Headless Chromium runs the JavaScript and builds the final page, like a browser that never clicks. (Breaks here: errors, blocked scripts, content that waits for a click) 3. **Index**: Google reads the rendered page, picks a canonical and stores the content for ranking. (Weakens here: missing text, changed canonicals, soft 404s) - **100%** of eligible HTML pages on nextjs.org were fully rendered by Google in a study of over 100,000 Googlebot fetches (Source: [Vercel and MERJ, 2024](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process)) - **10 s** median wait between crawl and render in that study. The 90th percentile was about 3 hours (Source: [Vercel and MERJ, 2024](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process)) - **15%** median difference between the raw and rendered visible word count of mobile home pages (Source: [Web Almanac 2024](https://almanac.httparchive.org/en/2024/seo)) So Google does render JavaScript, reliably on a healthy site. The study's authors note that rendering delays may differ on much larger sites with heavier scripts, and every other search engine and AI crawler has its own capabilities. JavaScript SEO isn't about whether Google can run your code. It's about making sure the important parts don't depend on things a crawler won't do. ### Server, Static or Client Rendering? How your pages are built decides what a crawler sees before any JavaScript runs. [web.dev's rendering overview](https://web.dev/articles/rendering-on-the-web) explains the trade-offs in depth; this table covers what matters for search. What each rendering approach puts in the initial HTML | Approach | Initial HTML | Search risk | | --- | --- | --- | | Static rendering | Complete pages built ahead of time. | Low. Content, links and metadata are present before any script runs. | | Server-side rendering | Complete HTML generated per request. | Low, if the server returns correct status codes and doesn't time out. | | Server rendering with hydration | Complete HTML, then JavaScript takes over interactivity. | Low to medium. Check that the hydrated page doesn't change titles, canonicals or content. | | Client-side rendering | A near-empty shell; JavaScript builds everything. | Higher. Everything depends on rendering, and errors leave nothing to index. | Google recommends server-side rendering, static rendering or hydration. It describes [dynamic rendering](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering), serving a pre-rendered copy only to bots, as a workaround it no longer recommends. If you're choosing a framework for a content or ecommerce site, pick one that can deliver the main content in the HTML. ### Patterns That Hide Content From Search **Links without a real href.** Google discovers pages by following `a` elements with a URL in `href`. Click handlers on spans, `javascript:` links and router components that don't output an `href` may never be followed. Google's [crawlable links guidance](https://developers.google.com/search/docs/crawling-indexing/links-crawlable) shows the patterns. HTML: links Google can and can't follow ~~~ Technical SEO Shoes Technical SEO Shoes Shoes Shoes ~~~ **Fragment URLs for routing.** Google can't reliably treat the part after `#` as a separate page, so views like `/#/products/shoes` and `/#/about` risk being seen as the homepage. Google's basics recommend the History API, which gives each view a real path. **Content that waits for an action.** Google Search doesn't interact with pages the way people do. It won't click or scroll, according to [Google's lazy-loading guidance](https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading), and its renderer declines permission prompts and clears cookies and local storage between page loads, according to the [JavaScript troubleshooting guide](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript). Text revealed only after a click on "Read more", products loaded only when someone scrolls, or content shown only after a location prompt may never be seen. Lazy loading that triggers when content becomes visible is fine. **Soft 404s.** A client-rendered app usually returns status 200 for every URL, then shows "Product not found" with JavaScript. Google sees a successful page with almost no content. Return real error codes from the server, or add a noindex to error views as a fallback. JavaScript: avoid a soft 404 in a client-rendered app ~~~ // When the API says the product doesn't exist, don't render an empty // "not found" view with a 200 status. Either send the visitor to a URL // the server answers with a real 404... if (!product) { window.location.href = '/not-found'; // server returns 404 here } // ...or, if you can't, keep the error view out of the index. if (!product) { const meta = document.createElement('meta'); meta.name = 'robots'; meta.content = 'noindex'; document.head.appendChild(meta); } ~~~ **Robots rules and canonicals changed by JavaScript.** If the server HTML says `noindex`, Google may skip rendering, so a script that removes it won't help. The noindex rule above works because it adds a restriction rather than removing one. Google also advises against using JavaScript to change the canonical URL to something different from the HTML. Keep both in the server response. The [noindex guide](https://ivig.dev/noindex-tag-guide/) covers the details. **Blocked or broken resources.** If robots.txt blocks the scripts or API endpoints the page needs, Google renders a broken page. A JavaScript error early in the bundle can stop everything after it. These show up in the URL Inspection live test. ### How to Test What Google Sees 1. **Compare source and DOM.** View the page source (Ctrl+U) to see the server HTML, and the DevTools **Elements** panel to see the rendered page. If your main text, links or title appear only in the second, you depend on rendering. 2. **Run the URL Inspection live test.** In Search Console, inspect the URL, select **Test live URL** and view the tested page. You get the rendered HTML, a screenshot, blocked resources and JavaScript console messages. 3. **Use the Rich Results Test without Search Console access.** It renders the page with Google's systems and shows the rendered HTML, even when the page has no structured data. 4. **Disable JavaScript as a quick check.** In DevTools, open the command menu (Ctrl+Shift+P), type "Disable JavaScript" and reload. What's left is roughly what crawlers without rendering see. 5. **Search for a unique sentence.** Once the page is indexed, search Google for an exact sentence that only appears after JavaScript runs. Absence isn't proof of a problem, but presence confirms the content was indexed. To speed up the first step, paste this snippet into the DevTools Console. It downloads the page's raw HTML again and prints a table comparing it with the rendered page. JavaScript: paste into the DevTools Console on any page ~~~ (async () => { const res = await fetch(location.href, { cache: 'no-store', credentials: 'omit' }); const rawDoc = new DOMParser().parseFromString(await res.text(), 'text/html'); const words = doc => { const body = doc.body ? doc.body.cloneNode(true) : null; if (!body) return 0; body.querySelectorAll('script, style, noscript, template').forEach(el => el.remove()); return body.textContent.split(/\s+/).filter(Boolean).length; }; const pick = doc => ({ title: doc.title || '(none)', canonical: doc.querySelector('link[rel="canonical"]')?.getAttribute('href') || '(none)', robots: doc.querySelector('meta[name="robots"]')?.getAttribute('content') || '(none)', h1: doc.querySelector('h1')?.textContent.trim().slice(0, 70) || '(none)', links: doc.querySelectorAll('a[href]').length, words: words(doc) }); console.table({ raw: pick(rawDoc), rendered: pick(document) }); })(); ~~~ Large differences in words or links, or a different title, canonical or robots value, show what depends on JavaScript. The raw request comes from your browser, so a server that treats Googlebot differently can return something else; URL Inspection is the authority for what Google received. The snippet only reads the page and changes nothing. ### Fixes in Order of Impact 1. **Put critical content in the server HTML.** Main text, headings, product details and internal links should exist before JavaScript runs. Move to server or static rendering for templates that matter for search. 2. **Use real links and real URLs.** Every page you want indexed needs a unique path and at least one `a href` pointing to it. Our [internal linking guide](https://ivig.dev/internal-linking-seo-guide/) covers the structure. 3. **Return correct status codes.** Missing content should produce a 404 or 410, moved content a redirect. See the [HTTP status codes guide](https://ivig.dev/http-status-codes-guide/). 4. **Keep metadata stable.** Titles, descriptions, canonicals and robots rules should be correct in the server response, not patched in later. 5. **Let Google fetch resources.** Don't block JavaScript, CSS or required API paths in robots.txt, and use versioned file names so Google doesn't render with outdated cached files. 6. **Watch speed.** Large bundles delay rendering for visitors too, affecting [LCP](https://ivig.dev/improve-lcp-guide/) and [INP](https://ivig.dev/improve-inp-guide/). **JavaScript SEO checklist** - Main content and headings appear in the page source, not only in the DOM - Every indexable view has its own URL without `#` routing - Navigation and pagination use `a` elements with real `href` values - Missing pages return 404 or 410, not a 200 with an error message - Robots rules and canonicals come from the server and aren't removed or changed by scripts - Robots.txt allows the scripts, styles and API paths needed to render - Content loads on visibility, not after clicks, scrolls or permission prompts - URL Inspection's live test shows the full content in the rendered HTML ### Frequently Asked Questions **Can Google index JavaScript content?+** Yes. Google renders pages with a headless version of Chromium and indexes the rendered result. Problems come from content that needs user actions, broken scripts, missing links or signals that only appear after rendering. **Is client-side rendering bad for SEO?+** It's riskier, not forbidden. Everything depends on rendering succeeding. For pages that need search traffic, server-side or static rendering removes that dependency and usually loads faster. **Do other search engines and AI crawlers render JavaScript?+** Not consistently. Capabilities differ by crawler and change over time. Content in the server HTML is available to all of them; content created by JavaScript may not be. **Should I use dynamic rendering?+** Google calls dynamic rendering a workaround and no longer recommends it. Use server-side rendering, static rendering or hydration instead. **How can I see the rendered HTML Google uses?+** Use the URL Inspection live test in Search Console and view the tested page, or the Rich Results Test if you don't have Search Console access. Both show the rendered HTML and a screenshot. ### Related Guides - [Understand crawling, rendering and indexing](https://ivig.dev/how-google-search-works/). - [Build crawlable internal links](https://ivig.dev/internal-linking-seo-guide/). - [Use noindex without JavaScript surprises](https://ivig.dev/noindex-tag-guide/). - [Diagnose pages that aren't indexed](https://ivig.dev/page-not-indexed/). --- ## Guide: Image SEO: Alt Text, File Names, Formats and Fast-Loading Images URL: https://ivig.dev/image-seo-guide/ Author: Milan Georgijevic Published: October 4, 2026 Images can bring visitors from Google Images, make pages easier to understand and decide how fast a page feels. Most of that comes from getting a few attributes right on every template. **Image SEO means helping search engines find, understand and quickly load your images.** In practice that comes down to real `img` elements, useful alt text, descriptive file names, efficient formats, responsive sizes and sensible lazy loading. This guide covers each one with copyable markup. If the page's titles and descriptions need work too, start with the [on-page SEO meta tags guide](https://ivig.dev/on-page-seo-guide/). ### How Google Finds and Understands Images Google discovers images through `img` elements in your HTML, including those inside a `picture` element. It doesn't index images added through CSS, such as a `background-image`. It then works out what an image shows from the image itself, the alt text, the file name and, above all, the text around it on the page. [Google's image SEO best practices](https://developers.google.com/search/docs/appearance/google-images) cover these signals, and they're the source for the recommendations in this section unless stated otherwise. Supported formats are BMP, GIF, JPEG, PNG, WebP, SVG and AVIF. Keep the file extension matching the real file type. An image also needs to sit on a page Google can crawl, so it can see the image in context. - **7.5%** of mobile sites use file names as alt text, which almost never describes the image (Source: [Web Almanac 2024](https://almanac.httparchive.org/en/2024/accessibility)) - **32%** of mobile images have width and height attributes, so most can shift the layout as they load (Source: [Web Almanac 2024](https://almanac.httparchive.org/en/2024/media)) - **42%** of mobile pages use srcset to offer different image sizes, up from 34% in 2022 (Source: [Web Almanac 2024](https://almanac.httparchive.org/en/2024/media)) Most image SEO work is fixing these basics across templates rather than tuning individual photos. A product template with no alt text or no dimensions repeats the problem on every product. ### Write Alt Text That Describes, Not Stuffs Alt text exists for people who can't see the image, including screen reader users and anyone whose images fail to load. Search engines use it too, but writing for the person gives the better result for both. Describe what the image shows and why it's on the page, in a short phrase. HTML: alt text from weak to useful ~~~ laptop repair, laptop screen repair, cheap laptop repair, laptop fix Technician fitting a new screen to a 14-inch laptop ~~~ Google's own example contrasts `alt="puppy"` with the more useful `alt="Dalmatian puppy playing fetch"`. Specific beats generic, and a description beats a keyword list. Not every image needs a description, though. The [W3C alt decision tree](https://www.w3.org/WAI/tutorials/images/decision-tree/) gives practical rules. What to put in the alt attribute | Image type | Alt text | Example | | --- | --- | --- | | Informative photo or illustration | A short description of what it shows that matters here. | `alt="Before and after photo of a cracked laptop screen"` | | Image inside a link or button | The destination or action, not the picture. | A logo linking home: `alt="iviG home"` | | Image of text | The same text, unless it's repeated nearby. | A banner reading Free Diagnostics: `alt="Free diagnostics"` | | Decorative image | Empty, so screen readers skip it. | `alt=""` | | Chart or diagram | A short summary, with the details in nearby text or a table. | `alt="Bar chart of image formats; table below"` | An empty `alt=""` and a missing alt attribute aren't the same. Empty means "decorative, skip it"; missing leaves screen readers to guess, often by reading out the file name. ### Name Files and Keep URLs Stable A file name is a small hint, but it's free. `laptop-screen-replacement.jpg` tells people and search engines more than `IMG_4821.jpg`. Use a few descriptive words separated by hyphens and keep it short. Rename files before you upload them; renaming later changes the URL. That matters because Google treats a new image URL as a new image. If a CMS or CDN changes image URLs on every deployment, Google has to discover and process them again. Keep URLs stable for images that matter, and redirect old image URLs if you have to move them. When the same image appears on several pages, use the same URL each time so it can be cached. ### Pick the Right Format and Compress It **JPEG and PNG still dominate**: Share of image requests on mobile pages by format, 2024 - JPEG (photos): 32.4% - PNG (graphics, screenshots): 28.4% - GIF (mostly tiny or legacy): 16.8% - WebP (photos and graphics): 12.0% - SVG (icons, logos): 6.4% - AVIF (photos): 1.0% Source: [Web Almanac 2024](https://almanac.httparchive.org/en/2024/media) media chapter. JPEG fell from 40% in 2022 while WebP and AVIF grew. A practical format choice | Format | Use it for | Watch out for | | --- | --- | --- | | JPEG | Photos when you need maximum compatibility. | Visible artifacts at high compression; no transparency. | | PNG | Screenshots, graphics with sharp edges, transparency. | Very large files for photos. | | WebP | A smaller default for both photos and graphics. | Check your CMS and email tools if images are reused there. | | AVIF | The smallest photos at similar quality. | Slower to encode; keep a fallback for older software. | | SVG | Logos, icons and simple illustrations. | Not for photos; sanitize uploaded SVG files. | Whatever the format, export images at the largest size they're displayed, not the camera's original resolution, and compare compression settings by eye. Many image CDNs, build tools and CMS plugins can produce WebP or AVIF automatically while keeping the original as a fallback. ### Serve the Right Size With Responsive Images A phone doesn't need the 2,000-pixel image a large desktop monitor uses. `srcset` lists the available widths and `sizes` tells the browser how wide the image will be displayed, so it can choose the smallest file that looks sharp. The `picture` element adds format choices. Google recommends always including an `img` with a `src` as the fallback. HTML: responsive image with a modern format and a fallback ~~~ Repair workshop with laptops lined up on an anti-static bench ~~~ The `width` and `height` attributes let the browser reserve the right space before the file arrives, which prevents layout shifts that count against [CLS](https://ivig.dev/core-web-vitals-guide/). Set them to the image's intrinsic size and let CSS scale it with `max-width: 100%; height: auto;`. An accurate `sizes` value matters: the [Web Almanac 2024](https://almanac.httparchive.org/en/2024/media) found the median mobile `sizes` attribute overstated the displayed width by 16%, so browsers fetched bigger files than needed. ### Lazy Load Without Hurting LCP `loading="lazy"` delays images until they're near the viewport. It saves data on long pages and is safe for search: Google's [lazy-loading guidance](https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading) supports the browser attribute and visibility-based scripts. Avoid scripts that load images only after a click or scroll, because Google doesn't interact with the page. Don't lazy-load images in the first screen, especially the largest one. It delays the image that usually decides Largest Contentful Paint. The [LCP guide](https://ivig.dev/improve-lcp-guide/) explains why and shows how to prioritize that image with `fetchpriority="high"` instead. **Check JavaScript lazy loaders in the rendered HTML.** Older lazy-load plugins put the real URL in a `data-src` attribute and swap it in with a script. If the swap fails, Google sees a placeholder. In URL Inspection, view the rendered HTML and confirm real image URLs appear in `src`, as Google's guidance recommends. ### Help Google Pick the Right Image For a search result thumbnail or a social share, you can point to the image that best represents the page. Google's documentation lists three ways: the `og:image` meta tag, the `primaryImageOfPage` property in structured data, or an image on the page's main entity. Choose a relevant, high-resolution image without extreme proportions or lots of text. Our [schema markup guide](https://ivig.dev/schema-markup-guide/) covers adding an image to Article or Product structured data. Put important images near the text they illustrate, give them captions where useful, and make sure the page's topic matches the image. An image sitemap can help Google discover images it might otherwise miss, including images served from a CDN on another domain. The [XML sitemap guide](https://ivig.dev/xml-sitemap-guide/) covers the format. ### Keep Images Out of Search When You Need To To stop Google indexing images that appear on a page, add `noimageindex` to that page's robots meta tag. To block specific image files wherever they appear, send an X-Robots-Tag `noindex` header with the files themselves. Both are documented in the [robots meta tag specification](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag), and the [noindex guide](https://ivig.dev/noindex-tag-guide/) explains how header rules work. Apache (.htaccess): keep image files out of Google Images ~~~ Header set X-Robots-Tag "noindex" ~~~ Narrow the pattern to a folder or file type you actually want hidden. A sitewide rule like this one would remove every image on the site from Google Images, including product photos that bring in visitors. ### Image SEO Checklist **Before publishing a page with images** - Important images use `img` elements, not CSS backgrounds - Informative images have short, specific alt text; decorative ones have `alt=""` - File names describe the image and URLs stay stable - Images are exported at their displayed size in WebP, AVIF or a sensible fallback - `srcset` and an accurate `sizes` value serve smaller files to phones - Every image has `width` and `height` to prevent layout shifts - Below-the-fold images lazy-load; the LCP image doesn't - The page's preferred image is set with `og:image` or structured data For a quick check on any live page, the free [TechSEO Inspector](https://ivig.dev/techseo-inspector/) extension includes an images check in its on-page audit. ### Frequently Asked Questions **Does alt text help SEO?+** Yes. Google uses alt text, along with the surrounding page content, to understand what an image shows. Its main job is accessibility, so describe the image for people and avoid keyword lists. **Should every image have alt text?+** Every image should have an alt attribute. Informative images need a description; purely decorative images should use an empty alt attribute so screen readers skip them. **Is WebP or AVIF better for SEO?+** Neither format is a ranking factor on its own. Both usually produce smaller files than JPEG or PNG, which helps pages load faster. Use whichever your tools support and keep a fallback where needed. **Can Google index CSS background images?+** No. Google indexes images in img elements, including inside picture elements, but not images added through CSS. Use an img element for anything you want to appear in Google Images. **Do I need an image sitemap?+** Not for most sites. Google finds images through your pages. An image sitemap helps when images are hard to discover, such as those loaded by JavaScript or served from another domain. ### Related Guides - [Speed up the largest image on the page](https://ivig.dev/improve-lcp-guide/). - [Write better titles and meta tags](https://ivig.dev/on-page-seo-guide/). - [Add images to structured data](https://ivig.dev/schema-markup-guide/). - [Prevent layout shifts and slow loading](https://ivig.dev/core-web-vitals-guide/). --- ## Guide: How to Improve INP: Find and Fix Slow Website Interactions URL: https://ivig.dev/improve-inp-guide/ Author: Milan Georgijevic Published: September 24, 2026 A fast-loading page can still feel slow when someone opens a menu, filters products or starts typing. Find the interaction responsible before changing scripts or buying another performance plugin. **To improve INP, identify a slow interaction, record what blocks its next visual update, and reduce the work on that path.** A smaller hero image might help loading, but it won’t necessarily fix a menu that freezes after a tap. This guide is for site owners working with a developer and developers investigating a specific complaint. It includes a local teaching example you can record yourself. For LCP, CLS and the broader measurement picture, start with the [Core Web Vitals guide](https://ivig.dev/core-web-vitals-guide/). ### What INP Measures Interaction to Next Paint measures responsiveness to qualifying clicks, taps and keyboard interactions across a page visit. It includes the wait before an event handler runs, the handler’s processing and the wait for the next paint. Scrolling and hovering aren't qualifying interactions. The reported value reflects the slowest interaction, with some outliers excluded on visits with many interactions. A good field INP is **200 milliseconds or less**; above 500 milliseconds is poor. Assess the 75th percentile separately for mobile and desktop, rather than expecting every interaction on every device to meet one number. These definitions and thresholds come from [Google's INP documentation](https://web.dev/articles/inp). INP isn't the time until a checkout payment finishes or a search request comes back. An interface can acknowledge an action promptly while waiting for the network. That acknowledgement must be honest: show “Submitting” while a request is pending, not “Order confirmed” before it succeeds. ### Choose a Real Interaction to Investigate Write down the page, action and conditions behind the complaint. “Mobile filtering freezes after selecting a size” is testable. “The website is slow” isn't specific enough to assign a fix. - Try opening the main navigation immediately after arriving. - Use a filter, select a product variant and add it to the cart. - Type into search or a form with live validation. - Test cookie preferences, expandable answers and chat controls. - Repeat the action after the page has been open for a while. Record whether it happens only on first use, only with a large result set, or only after a third-party widget loads. Save the exact steps so a second person can reproduce the same behavior. Field data tells you whether real visitors have a problem; a local recording helps explain one instance. PageSpeed Insights can show CrUX data when available, while real-user monitoring can provide interaction-level context. [Google's INP optimization guidance](https://web.dev/articles/optimize-inp) recommends connecting those two kinds of evidence. Missing field data is not proof of either good or poor responsiveness. ### Record the Click in Chrome DevTools 1. Open the affected page and Chrome DevTools. Select **Performance**. 2. Record the browser version, device and any CPU or network throttling. Keep those settings the same when comparing changes. 3. Start a runtime recording, perform the chosen action once, then stop. 4. Find the interaction in the timeline and inspect the corresponding main-thread activity. 5. Look for work before the handler, within the handler and before the visual update. Follow script locations into your code where possible. 6. Save the trace with reproduction steps, then repeat to check that the result isn't a one-off. Use the [official runtime performance walkthrough](https://developer.chrome.com/docs/devtools/performance) for the panel controls. A runtime recording is useful here because a loading-only test may never open the menu or apply the filter that's causing trouble. Keep the environment representative. An extension-free browser is helpful for isolating your code, but also test the actual consent state, widget combination and device class your visitors use. CPU throttling is a diagnostic approximation, not a substitute for checking a real phone. ### Match the Fix to the Work You Found Three places an interaction can wait | Where the delay occurs | What to inspect | A targeted experiment | | --- | --- | --- | | Before the handler | Startup scripts, timers or other work already occupying the main thread. | Delay one nonessential widget on staging, then repeat the same action. | | Inside the handler | Filtering, validation, repeated calculations or updating many elements. | Remove unnecessary work; split independent work into smaller tasks. | | Before the next paint | Expensive layout or a large interface update after the handler. | Reduce the changed DOM and separate layout reads from writes. | Inspect the trace instead of guessing from a function name. A short-looking UI function can trigger a lot of rendering work. For rendering problems, look for repeated style changes followed immediately by layout measurements. Batch measurements before updates where the behavior allows it. Chrome's [layout performance guide](https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing) explains why repeated read/write cycles can be expensive. When the expensive work is calculation rather than DOM manipulation, a web worker may be worth considering. Workers can't directly update the page's DOM, and moving data between threads has a cost. First remove work that isn't needed at all. ### A Copyable Example You Can Record Save the following as a local HTML file and open it in Chrome. It deliberately wastes CPU time to make the difference easy to inspect. **Never add the artificial work function to a production website.** The first button changes some text and immediately blocks the main thread. The browser cannot show that intermediate state while the task is running. The second gives feedback a chance to paint, then splits the same nominal amount of artificial work into smaller tasks. ![Local teaching example with a blocking button and a second button that splits work into smaller tasks](https://ivig.dev/assets/guides/inp-response-demo.png) Screenshot of this teaching example, not a measured result from a client website. HTML: local teaching example only ~~~ Responsiveness teaching demo

One task, two response patterns

Local teaching example. Artificial work, not a benchmark or a production fix.

One blocking task

Ready

Feedback, then smaller tasks

Ready

~~~ Record each button separately. Look for one long block versus repeated smaller blocks, and inspect when the feedback can appear. The split version can take longer to finish because scheduling adds overhead. Finishing sooner and responding sooner are different goals. The example uses a rendering opportunity followed by a new task. Merely adding `async` to a function, or awaiting an already-resolved promise, doesn't move heavy synchronous work off the main thread. For real workloads, see [Google's guide to breaking up long tasks](https://web.dev/articles/optimize-long-tasks), including yielding options and compatibility considerations. Don't defer work required to validate a purchase, preserve data or display the correct result. Give useful pending feedback and keep failure handling intact. Splitting a loop also requires thinking about cancellation and stale results if the user changes their selection midway through. ### Verify the Fix Without Overclaiming Retest the same action before and after the change with matching settings and data. Then test adjacent actions: opening and closing the menu repeatedly, submitting invalid input, using the keyboard and navigating away during a pending operation. - Did the relevant work disappear or move out of the interaction's critical path? - Does the next visual update represent the real state? - Can a second click, cancellation or failed request break the interface? - Does the change help on a representative phone, not only your laptop? - After release, does real-user evidence support the local result? Keep the release date and the affected interaction in your change log. Field reports aggregate many visits; one fast local click does not prove the whole site's INP has improved. A better INP also doesn't guarantee higher rankings. The immediate objective is a usable interaction that doesn't leave people wondering whether their tap registered. If the page is indexed but gets little search visibility, investigate relevance and search demand separately using the [indexed-but-not-ranking checklist](https://ivig.dev/indexed-but-not-ranking/). ### Frequently Asked Questions **Can a static website have poor INP?** Yes. Static HTML can still load expensive scripts, widgets or event handlers. Test the interactions the page actually provides; the hosting or framework label does not establish responsiveness. **Will compressing images fix INP?** Not necessarily. Image optimization mainly addresses loading and rendering costs. Identify the work delaying the specific interaction before choosing a fix. **Is my local test the same as my field INP?** No. A local recording explains interactions under your test conditions. Field INP reflects qualifying interactions during real visits across different devices and page states. **Should I add the demonstration code to my website?** No. Its artificial CPU work is only for a local teaching example. Apply the scheduling principle to a measured real workload and test correctness, cancellation and errors. ### Related Guides - [Understand all three Core Web Vitals](https://ivig.dev/core-web-vitals-guide/). - [Put performance in a technical SEO plan](https://ivig.dev/technical-seo-guide/). - [Investigate visibility after indexing](https://ivig.dev/indexed-but-not-ranking/). --- ## Guide: Indexed but Not Ranking? How to Find What’s Holding Your Page Back URL: https://ivig.dev/indexed-but-not-ranking/ Author: Milan Georgijevic Published: September 24, 2026 Being in Google’s index and earning useful search visibility are different things. Use this checklist to separate a reporting issue, an intent mismatch and a page that needs a better answer. **If your page is indexed but not ranking for the searches you care about, stop treating it only as an indexing problem.** First verify the exact URL, then investigate what people search for, which page Google shows and whether your page actually meets that need. This is a diagnosis workflow, not a promise of a first-page result. Use it for one important URL before making broad changes across your site. If URL Inspection says the page is not indexed, use the separate [indexing troubleshooting guide](https://ivig.dev/page-not-indexed/). ### Confirm What “Indexed” Means for This URL Inspect the full preferred URL in Search Console, including the protocol, host and trailing slash. Read the indexed result, last crawl and Google-selected canonical where available. The live test checks the current page; it doesn't replace Google's processed index information. “URL is on Google” means the page can appear, not that it must appear for every relevant search. Google's [URL Inspection documentation](https://support.google.com/webmasters/answer/9012289) makes that distinction. If Google selected a different canonical, investigate that relationship before judging the requested URL's performance. Also open the page as a visitor. Check that the main answer is present, navigation works and the page hasn't become an error message with a successful status code. An older indexed snapshot doesn't prove today's page still works. Don't use a single manual search as your baseline. Location, device and query wording affect what you see. A `site:` search can be a quick discovery check, but it isn't a complete ranking report. Record actual queries and page-level evidence instead. ### Name the Symptom Before Choosing a Fix Different symptoms need different investigations | What you observe | What it might mean | Next check | | --- | --- | --- | | Almost no impressions | Limited demand, little visibility, a new page or the wrong report/filter. | Confirm the property, URL, date range and query task. | | Impressions but low positions | The page appears, but is not competitive for those searches. | Inspect the queries, result types and usefulness of the answer. | | Visible positions but few clicks | An unappealing result, mixed query intent or a search answered on the results page. | Review actual queries and snippets, not just overall CTR. | | Another URL gets the relevant traffic | A better-fitting page or potentially confusing overlap. | Compare both pages before merging anything. | | Previously visible, now declining | A change in demand, competitors, the site or search systems. | Compare dates and inspect the timing of known changes. | These are hypotheses, not diagnoses. A small site with a handful of impressions doesn't have enough evidence to support a precise explanation. You can still improve an obviously incomplete page, but label the reason as an editorial judgment rather than a conclusion from sparse data. ### Read Search Console at the Page and Query Level 1. Open the Search results Performance report for the correct property. 2. Apply an exact page filter for the preferred URL. Keep the search type consistent. 3. Choose a useful period, then compare an equal-length period with similar weekday coverage. 4. Review the Queries tab. Separate branded searches from non-branded searches that match the page's job. 5. Check country and device when the audience or result differs by market. 6. Record clicks, impressions, CTR and position together, along with every active filter. The [Search Console filtering documentation](https://support.google.com/webmasters/answer/17011165) explains the available comparisons. Start with one clear question, such as whether a service page is appearing for local service searches, rather than adding filters until the graph looks convincing. Some queries are hidden for privacy, and most performance data is assigned to canonical URLs. That can explain gaps between visible rows and totals or a variant URL with little data. See Google's [Performance report dimensions guidance](https://support.google.com/webmasters/answer/17011259). A missing query row doesn't prove nobody searched for it. Average position is an aggregate, not a fixed rank for one keyword. For a walkthrough of the metrics and exports, use the [Search Console Performance guide](https://ivig.dev/google-search-console-performance-guide/). ### Check Whether You Built the Right Kind of Page Pick a small set of queries that genuinely matter to the business. Look at the current results for the audience and market you're trying to serve. Note whether they mainly offer instructions, product selections, local providers, definitions or comparisons. Treat this as evidence about the task, not permission to copy the results. Consider a fictional laptop repair business. Its page titled “Laptop Battery Replacement” might target three very different needs: Illustrative query mapping, not observed client data | Query | Likely task | Useful page content | | --- | --- | --- | | how to replace a laptop battery | Do the repair yourself. | Model-specific steps, safety limits, tools and situations needing professional help. | | laptop battery replacement cost | Estimate the price and compare options. | What changes the price, what is included and how to obtain a relevant quote. | | laptop battery replacement near me | Find a provider. | Service area, supported devices, availability, contact details and the booking process. | A generic essay may be relevant to the words but still fail the task. Don't add “near me” repeatedly to an instructional article. Decide which need the page should serve and make that purpose obvious in its title, opening answer and main sections. Some searches have mixed intent, and results change. If the evidence is ambiguous, record that uncertainty and use customer questions to decide what the page can honestly deliver. Our [search intent guide](https://ivig.dev/search-intent-guide/) explains that mapping in more detail. ### Improve the Answer, Not Just Its Length Ask what a reader still needs after reaching the end of the page. Then add the missing answer you are qualified to give. That may be a worked example, product compatibility details, an explanation of limitations or a clearer next step. It isn't automatically another thousand words. Google's [people-first content guidance](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) emphasizes original value, clear sourcing and trustworthy authorship. Use those as review questions, not a scoring formula. - **Accuracy:** Are instructions current, specific and supported where necessary? - **Experience:** Can you show your own process, screenshots or a properly attributed example? - **Completeness:** Does the page answer the next practical question without wandering into unrelated topics? - **Trust:** Is it clear who wrote it, what they know and where its limits are? - **Usability:** Can a reader find the answer on a phone and complete the next action? For the repair-cost example, useful work might be explaining what a quote includes and why models differ. Inventing a national “average price” without a sound source would weaken the page. If you don't have evidence for a claim, qualify it or leave it out. ### Check Internal Links, Overlap and Technical Friction Open the most relevant related pages on your own site. Can someone naturally reach this page from them? Add a descriptive link where it helps the reader continue, not a block of repeated keywords in every footer. Google's [link guidance](https://developers.google.com/search/docs/crawling-indexing/links-crawlable) covers crawlable links and useful anchor text. Look for another page doing the same job. Similar vocabulary is normal; indistinguishable purpose deserves a closer look. Use the [keyword cannibalization guide](https://ivig.dev/keyword-cannibalization-guide/) before redirecting or canonicalizing pages. Check technical obstacles proportionately: incorrect canonicals, unavailable main content, broken forms and disruptive mobile layouts deserve attention. If interactions freeze, use the [INP troubleshooting guide](https://ivig.dev/improve-inp-guide/). A performance score is not a substitute for answering the searcher's question. For a sudden broad decline, check Search Console's Manual actions and Security issues reports and review known releases. Google's [traffic-drop investigation guide](https://developers.google.com/search/docs/monitor-debug/debugging-search-traffic-drops) also covers demand changes and search-system changes. A traffic drop alone doesn't prove a penalty. ### Choose One Improvement and Keep a Review Record Create a short record with the URL, intended query task, current evidence, proposed change and the outcome you'd expect. For example: “The cost guide gets relevant impressions but doesn't explain what a quote includes. Add a clear breakdown and link to the booking page.” That's a testable editorial choice, not a guaranteed ranking fix. Save the original content and release date. Check that the revised page is live, retains its intended canonical and works on mobile. Later, compare relevant query groups over comparable periods, allowing for seasonality and changes in query mix. Look beyond a single average position: are useful impressions and clicks changing, are the intended landing pages appearing, and are qualified enquiries improving where measurement is available? If several changes shipped together, don't claim one small edit caused the whole result. There is no universal number of days after which an indexed page should rank well. Repeated indexing requests don't create relevance or make the page more useful. Google describes ranking as the work of [multiple systems and signals](https://developers.google.com/search/docs/appearance/ranking-systems-guide), not a single checklist you can complete for guaranteed placement. ### Frequently Asked Questions **Does indexed mean my page will rank?** It means the page is eligible to appear, not that it will appear prominently for your target queries. Visibility depends on the search and how the page compares with other available results. **Should I request indexing again to improve rankings?** Repeated requests are not a ranking strategy. Verify important changes and focus on the page’s relevance, usefulness, internal connections and technical correctness. **Should I change the URL of a page that is not ranking?** Not just because it has little traffic. A URL change adds migration work and does not fix an intent mismatch or a weak answer. Change it only for a clear reason and plan the redirect when appropriate. **What if the page has almost no Search Console data?** Confirm your property and filters, then make proportionate checks of purpose, content and links. Sparse data cannot reliably identify a precise cause, and missing query rows are not proof of zero demand. ### Related Guides - [Troubleshoot pages that are not indexed](https://ivig.dev/page-not-indexed/). - [Match the page to the searcher’s task](https://ivig.dev/search-intent-guide/). - [Investigate overlapping pages](https://ivig.dev/keyword-cannibalization-guide/). --- ## Guide: Keyword Cannibalization: When Your Pages Compete and When They Don’t URL: https://ivig.dev/keyword-cannibalization-guide/ Author: Milan Georgijevic Published: September 24, 2026 Two pages appearing for the same keyword is not automatically a problem. Find out whether the overlap actually confuses the page’s purpose or sends visitors to the wrong place before removing content. **Keyword cannibalization is an SEO term for harmful overlap between pages that target substantially the same search need.** The important word is harmful. Two URLs receiving impressions for the same query doesn’t, by itself, show that either should be removed. This guide uses fictional examples and a repeatable Search Console workflow. It doesn’t label every URL switch as a penalty or assume merging pages will improve rankings. If the main issue is an indexed page with little visibility, first use the [indexed-but-not-ranking checklist](https://ivig.dev/indexed-but-not-ranking/). ### What Counts as a Real Problem? Start with three questions: do the pages do the same job, is the wrong page appearing for a useful query, and is there a practical cost? That cost might be visitors landing on an outdated explanation, maintaining two conflicting answers or having no clear page to link to from related content. Google's [ranking systems overview](https://developers.google.com/search/docs/appearance/ranking-systems-guide) describes relevance and multiple ranking signals. Don't interpret the practitioner label “cannibalization” as proof of a named Google penalty. One site's URLs can be relevant to more than one query, and one query can have more than one reasonable answer. Overlap signals are starting points, not verdicts | Observation | Interpretation | Action | | --- | --- | --- | | A service page and a how-to guide share a phrase | They may serve different stages and needs. | Check their purpose and the queries bringing visitors. | | Two guides answer the same question with nearly identical sections | The distinction may be hard to justify. | Compare useful differences and maintenance requirements. | | Different URLs appear in different weeks | Results or query mix may have changed. | Hold query, device and country consistent before judging. | | An outdated page gets the relevant visits | People may receive the wrong answer. | Review whether to update it, differentiate it or retire it. | If both pages serve readers well, overlap may be harmless. Don't create a cleanup project merely because an SEO tool listed two URLs beside one keyword. ### Make a Small Page-Purpose Map Choose one suspected group, not the entire site. For each URL, record its main audience, the task it helps complete, its distinctive information and the next step it offers. Read the actual pages rather than comparing only titles. Here is an illustrative map for a fictional repair business. These are example paths, not live pages or client results. Fictional laptop-repair content map | Page | Main job | Initial decision | | --- | --- | --- | | /laptop-repair/ | Help a local customer assess and book a repair service. | Keep as the service destination. | | /laptop-repair-cost/ | Explain what affects repair pricing and what a quote includes. | Keep as a pricing explanation if it adds useful detail. | | /how-much-to-fix-a-laptop/ | Answer the same pricing question using the same examples. | Investigate a merge with the cost guide. | | /replace-laptop-battery/ | Explain a specific repair process and its safety limits. | Keep distinct if the instructions are useful and qualified. | The two cost articles are candidates for consolidation because their purpose overlaps. The service and instructional pages are not duplicates merely because they mention laptop repair. Our [keyword research guide](https://ivig.dev/keyword-research-guide/) explains how grouping queries by need can prevent this confusion before publication. ### Check the Suspected Overlap in Search Console 1. Open the Search results Performance report and select a consistent search type and date range. 2. Filter to one exact query that matters to the suspected group. 3. Open the Pages tab to see which reported URLs appeared for that query. 4. Compare equal periods. Hold device and country constant when investigating a particular audience. 5. Inspect each candidate page's query pattern separately so you don't miss its other useful searches. 6. Save the filters and exports with your page-purpose notes. Use Google's [filtering and comparison instructions](https://support.google.com/webmasters/answer/17011165) for the controls. Broader query groups can help later, but an exact query is a clearer starting point than a mix of unrelated searches containing one word. Search Console reports most performance data against the canonical URL and hides some queries for privacy. The table isn't a complete record of every search. Google's [report dimensions documentation](https://support.google.com/webmasters/answer/17011259) explains these limits. A separate Queries export and Pages export don't establish which query belonged to which page. Don't join them by row number. Apply the query filter before reviewing pages, or use a report that actually includes both dimensions together. See the [Performance report guide](https://ivig.dev/google-search-console-performance-guide/) for interpreting the metrics. If the report shows little data, rely on the evident content overlap to make a proportionate editorial decision. Don't invent a traffic loss or assign a precise ranking impact you cannot observe. ### Look for Harm, Not Just a Changing URL Review the group as a whole. If one page loses clicks while the other gains useful visits, the business may not have lost anything. Equally, a steady total can hide a poor landing experience if visitors reach an outdated or unsuitable page. Compare relevant clicks across the affected pages, then read the queries behind the change. Treat impression totals carefully: two pages can appear in the same search, so summing page impressions isn't a count of unique searches. Keep query mix and reporting scope consistent. Write down the suspected consequence in plain language. “Both articles tell readers how pricing works, but one contradicts our current process” is enough to justify fixing the contradiction. “Google keeps alternating URLs, therefore it is confused” is an interpretation that needs more evidence. Also check for changed demand, new content, a redesign or a measurement change. A before-and-after comparison isn't a controlled experiment. You can report what changed without claiming a merge alone caused it. ### Keep, Differentiate or Merge? Choose by purpose and evidence | Decision | Use it when | Implementation | | --- | --- | --- | | Keep both | Each page serves a clear, useful and distinct task. | Make the distinction obvious and link between them where helpful. | | Differentiate | Both deserve to exist, but their present scope is muddled. | Rewrite titles, opening answers and sections around separate needs. | | Merge and redirect | One maintained answer can replace redundant pages without losing valuable coverage. | Combine useful material, then permanently redirect retired URLs to the relevant replacement. | | Canonicalize an alternate | Duplicate content must remain available at another URL. | Declare the preferred equivalent URL and keep other signals consistent. | A canonical tag isn't a way to nominate your favorite page among different topics. Google's [canonicalization guidance](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) concerns duplicate or very similar pages. For the visitor-facing difference, read [canonical tags versus 301 redirects](https://ivig.dev/canonical-vs-301-redirect/). Don't apply `noindex` simply because two pages share a keyword. That can remove a useful page from search without transferring its purpose to a replacement. Likewise, changing a title alone won't differentiate two articles that still deliver the same answer. ### A Safe Merge Checklist 1. **Choose the destination deliberately.** Consider its purpose, existing useful traffic, links, stable URL and suitability for the combined answer. Don't choose only the shorter slug. 2. **Preserve useful material.** Move distinct examples, explanations and reader questions into a coherent replacement. Keep supporting sources and update inaccurate details. 3. **Check the reader's journey.** Someone following an old link should still get a relevant answer. If not, the proposed merge may be too broad. 4. **Save the previous versions.** Record an exact old-to-new URL map and a way to reverse a mistaken change. 5. **Publish the replacement first.** Verify the content, successful response and intended self-referencing canonical. 6. **Redirect the retired URLs.** Use a permanent redirect for a permanent move. Update internal links and sitemap entries to the destination. 7. **Test old and new addresses.** Confirm the route, avoid loops and chains, and check mobile navigation and important forms. Google's [redirect documentation](https://developers.google.com/search/docs/crawling-indexing/301-redirects) describes the status choices. Do not send a retired detailed guide to the homepage just because that is convenient. Relevance of the replacement matters to the person following the old address. ### Review the Group After the Change Keep a dated record of what was merged, differentiated or left alone and why. Verify technical behavior immediately. Later, review the same relevant query groups over comparable periods and check the destination's processed indexing information. Evaluate combined useful clicks and landing-page suitability, not whether every old URL still has traffic. Losing separate visibility for a deliberately retired page is expected; losing its unique useful coverage is not. For prevention, add a page-purpose check to every content brief: “Which existing page already answers this need, and what will the new one do differently?” Link a supporting article to the main service or topic page when that helps the reader. Our [internal linking guide](https://ivig.dev/internal-linking-seo-guide/) explains how to make those relationships clear without repetitive anchor text. Sometimes the best next publication is an update to an existing page. Sometimes a new guide is justified because it answers a different question. The page map should make that decision easier, not enforce one keyword per URL as a rigid rule. ### Frequently Asked Questions **Is keyword cannibalization a Google penalty?** Do not treat the term as a named penalty. It is a practitioner label for potentially harmful content overlap. Diagnose the page purposes and observed consequences rather than assuming punishment. **Can two pages rank for the same keyword?** Yes. Shared query visibility alone does not prove harm. Check whether the pages meet different needs and whether visitors reach useful, accurate answers. **Should I merge every pair of similar articles?** No. Keep pages that serve distinct useful tasks. Merge only when a relevant replacement can preserve the valuable information and the separate pages no longer need to exist. **Can a canonical tag fix competing pages?** Only consider canonicalization when the content is duplicate or very similar and an alternate needs to remain accessible. Different pages sharing a keyword are not automatically canonical alternatives. ### Related Guides - [Map queries before writing another page](https://ivig.dev/keyword-research-guide/). - [Separate duplication from content overlap](https://ivig.dev/duplicate-content-seo-guide/). - [Choose the right URL treatment](https://ivig.dev/canonical-vs-301-redirect/). - [Investigate other causes of weak visibility](https://ivig.dev/indexed-but-not-ranking/). --- ## Guide: Canonical Tag vs. 301 Redirect: Which Should You Use? URL: https://ivig.dev/canonical-vs-301-redirect/ Author: Milan Georgijevic Published: 2026-09-19 Updated: 2026-09-19 Use a 301 redirect when the old URL should send visitors to its replacement. Use a canonical tag when a duplicate or near-duplicate page must remain accessible, but you want another URL to represent it in search. The first changes the route a visitor takes; the second describes a relationship between pages. The phrase "canonical redirect" often mixes these two jobs together. Before changing a tag or server rule, ask a simpler question: should someone opening the old URL still be able to use that page? This guide turns that answer into a practical choice, with fictional example URLs you can adapt to your site. ### The Difference That Matters | Question | Canonical link element | 301 redirect | | --- | --- | --- | | What happens to the visitor? | They stay at the requested URL. | Their browser follows the response destination. | | Does the source page remain usable? | Yes, in the normal duplicate-page setup. | No. The old address sends the visitor onward. | | Where is it configured? | Usually the page’s HTML head. | Usually the server, hosting settings or a CMS redirect manager. | | What should I check first? | Whether the content is equivalent and both versions need to exist. | Whether the replacement satisfies the original page’s purpose. | Google treats permanent redirects and `rel="canonical"` as strong canonicalization signals, not two competing tricks for increasing rankings. Keep your preferred URL consistent across links and sitemaps. A canonical declaration doesn't force Google to choose it. See Google's [canonicalization guidance](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls). In HTML, a canonical is a `` element, not a `` element. For the broader rules, including PDFs and pagination, read the [canonical URL implementation guide](https://ivig.dev/canonical-url-guide/). Here we'll focus on choosing and checking the right treatment. ### Choose by What the Visitor Should Experience | Situation | Practical choice | Reason | | --- | --- | --- | | A guide has moved to a new address | Permanent redirect | A bookmarked old address should reach the replacement. | | A print-friendly version must stay available | Canonical to the main article | Readers can still print while the main article is your preferred search version. | | Two overlapping guides have been combined | Redirect retired guides after checking the merged content | Each old reader should find a useful replacement, not a thin summary. | | A filter produces a genuinely different useful product selection | Assess it separately | Sharing a template is not enough to make two pages duplicates. | | An expired page has no relevant replacement | Consider a real 404 or 410 | Sending everybody to the homepage does not replace the missing answer. | | A temporary outage needs a temporary destination | Assess a temporary redirect | Do not label a short-term change as a permanent move. | For a shop, write down what customers lose if you redirect a variant: a selected size, stock information or a useful filter state. For an article, compare the actual answers, not just its title. These checks prevent a technically valid configuration from becoming a poor user experience. ### Example: Keep a Print Version Available Imagine a fictional site with a normal guide at `https://example.com/guides/packing/` and a print-friendly copy at `https://example.com/guides/packing/print/`. Both contain the same advice. The print version removes navigation and keeps a layout readers use. In this setup, a redirect would defeat the print view's purpose. Put the following preference in the `` of the print page, and use the same self-referencing declaration on the main guide: HTML: fictional print-page example ~~~ ~~~ Then test both browser journeys: the normal guide must stay normal, and the print view must still print. List the main guide in the sitemap and use it for ordinary article links. Keep a clearly labeled print link where readers need that alternate view. This example is about equivalent content, not permission to canonicalize unrelated pages. ### Example: Move an Outdated Guide Now imagine `/packing-tips-2024/` has been replaced by `/guides/packing/`. You have checked that the new guide still answers the useful questions from the old one. There is no reason to keep a second readable copy at the dated address. The old URL should return a response like this. This is a response illustration, not code to paste into an HTML file: HTTP response: fictional example ~~~ HTTP/1.1 301 Moved Permanently Location: https://example.com/guides/packing/ ~~~ The browser follows the `Location` header. The new page should then return its own successful response and show the expected content. MDN documents the [301 response and Location header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/301). Use your platform's redirect facility, or ask a developer to add an exact source-to-destination rule. Avoid pasting a generic server rule without checking the hosting setup: a broad match can redirect other pages or create a loop. Google recommends permanent server-side redirects for permanent moves; both 301 and 308 are permanent status codes. Temporary redirects serve a different purpose. Read the [official redirect guidance](https://developers.google.com/search/docs/crawling-indexing/301-redirects) or our [HTTP status code guide](https://ivig.dev/http-status-codes-guide/) before choosing a code. ### When a Canonical Points to a Redirect A crawler warning such as "canonical points to redirect" describes an indirect route. For example: Fictional URL relationship ~~~ /packing/print/ --canonical--> /packing-tips-2024/ /packing-tips-2024/ --301--> /guides/packing/ ~~~ The first page still names yesterday's address as preferred. If the final guide really is its equivalent, update the print page to name `/guides/packing/` directly. This makes the relationship easier to maintain and test. - Follow the route. Record every destination, including changes of host or protocol. - Read the final page. A successful response is not proof that the content matches. - Check its indexing settings. A final page with `noindex` is not a sensible preferred search destination. - Update the originating template. Fix all affected print pages or variants, not just the sample URL from the warning. - Retest links and the sitemap. They should not keep promoting the retired address. Don't automatically replace every canonical with whatever URL a redirect happens to reach. A misconfigured rule might end at the homepage or an error screen. Google's [canonical troubleshooting guide](https://developers.google.com/search/docs/crawling-indexing/canonicalization-troubleshooting) explains how conflicting declarations can lead to unexpected choices. ### An Implementation Plan for Your Developer A short mapping document is more useful than a request to "fix duplicate content." For each group, record the source URL, preferred URL, intended visitor behavior, reason, owner and verification date. Include a small sample of pages that must not change. | Source | Requested behavior | Acceptance check | | --- | --- | --- | | /packing-tips-2024/ | 301 to /guides/packing/ | Opening an old bookmark reaches the updated guide. | | /guides/packing/print/ | Remain available; canonical to /guides/packing/ | Print layout still works and names the main guide. | | /guides/cabin-baggage/ | Leave independent | Distinct baggage advice remains accessible at its own URL. | Before release, save the current configuration and agree how to reverse an incorrect rule. Test one representative group first. After release, update menus, article links and sitemap entries to the final preferred addresses. For larger URL moves, Google advises keeping redirects for at least a year; keeping them longer can also help people using old links. See its [site-move checklist](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes). ### How to Check the Result #### 1. Check the actual browser route Open an old address in a private window. Watch the address bar and inspect the document request in your browser's Network panel. For a redirect, record the status and destination. For a retained alternate, confirm the page stays open. If results differ from your change, investigate cached responses and hosting/CDN rules before editing again. Developers can inspect response headers with curl. These commands request headers using a normal GET and discard the body; the second follows redirects. Replace the fictional URL before running them: Terminal: inspect, then follow ~~~ curl -sS -D - -o /dev/null https://example.com/packing-tips-2024/ curl -sS -L --max-redirs 10 -D - -o /dev/null https://example.com/packing-tips-2024/ ~~~ #### 2. Check the destination and retained alternate Inspect their HTML head and any canonical HTTP headers. Confirm the URL is intentional, not a leftover staging domain or previous slug. Check the page content, response status and robots settings together. A green response code alone is not a complete SEO test. #### 3. Check Google's processed version separately In Search Console, inspect the URLs and compare the user-declared and Google-selected canonical where available in the indexed data. The live test can check current accessibility, but it cannot tell you which canonical Google will ultimately select. Google's [URL Inspection documentation](https://support.google.com/webmasters/answer/9012289) explains this distinction. Record the last crawl date so you don't mistake an older snapshot for a failed release. Implementation checks and search outcomes are separate. A correct redirect is testable now; recrawling, canonical selection and any ranking changes happen later. Use the [Search Console performance guide](https://ivig.dev/google-search-console-performance-guide/) to compare equal periods without interpreting tiny samples as a trend. ### Mistakes to Avoid - Using canonical tags as a migration shortcut. Old bookmarks still open the old page. If you want visitors moved, solve that navigation problem. - Redirecting distinct pages just because their keywords overlap. Compare the answers and audience before merging. - Adding noindex to force a canonical choice. Exclusion and consolidation are different goals. Review the [duplicate-content decision process](https://ivig.dev/duplicate-content-seo-guide/) first. - Fixing one URL but leaving its template unchanged. The next publish can recreate the same problem. - Expecting a guaranteed traffic increase. Cleaner signals do not create demand, stronger content or better rankings on their own. ### Unsure Which URLs to Keep or Redirect? Request a free website review. I'll look at a small selection of public pages and email up to five priority findings or next steps. Larger URL mapping and implementation work can be scoped separately. [Request a free website review](https://ivig.dev/#free-audit) ### Frequently Asked Questions **Is a canonical tag the same as a 301 redirect?** No. A canonical tag suggests a preferred URL without moving the visitor. A 301 is an HTTP response that sends the browser to a different URL. Decide whether the original page should remain usable before choosing. **What should I do when a canonical points to a redirect?** Check the final destination first. If it is the correct equivalent page, change the canonical to that final URL and update internal links and the sitemap. Do not automatically accept an unrelated redirect destination. **Can I use a redirect and a canonical together?** Yes, on different parts of the route. An old URL can redirect to a new page, and the new page can have a self-referencing canonical. Do not rely on an HTML canonical in a redirect response. **Will a canonical tag remove the old page immediately?** No. It does not move users or guarantee that Google will select your preferred URL. Search engines need to crawl and process the pages. Check the indexed URL Inspection data for the selected canonical. **Should a deleted page redirect to the homepage?** Only if the homepage genuinely replaces that page, which is unusual. Choose a relevant replacement when one exists. Otherwise, a proper 404 or 410 is usually more appropriate than an unrelated redirect. ### Related Guides - [Implement canonical URLs correctly](https://ivig.dev/canonical-url-guide/). - [Understand redirects and other HTTP status codes](https://ivig.dev/http-status-codes-guide/). - [Create a sitemap of your preferred URLs](https://ivig.dev/xml-sitemap-guide/#create). - [Check your titles, meta tags and indexing settings](https://ivig.dev/on-page-seo-guide/). --- ## Guide: How to Read Google Search Console: Clicks, Impressions, CTR and Average Position URL: https://ivig.dev/google-search-console-performance-guide/ Author: Milan Georgijevic Published: September 18, 2026 A practical guide to the four headline metrics, fair comparisons and a repeatable review. Learn what the numbers can tell you, what they leave out and when a change is worth investigating. **Google Search Console tells you how your website appears in Google Search and which results bring people to it.** Its Performance report is useful once you stop treating every red percentage as a problem and start asking what changed for a particular page and audience. This guide is about reading the data, not connecting your website. If you haven't verified ownership yet, start with the [Search Console setup walkthrough](https://ivig.dev/google-search-console-setup/). You don't need a paid reporting tool for the review below. ### The Four Metrics, in Plain Language Open the Search results Performance report and enable clicks, impressions, average CTR and average position. Keep the selected property and search type in mind: the figures describe that report, not every visit to your business. | Metric | What it describes | What it doesn't prove | | --- | --- | --- | | Clicks | Clicks from Google Search results to your site. | Unique visitors, leads or sales. | | Impressions | Recorded appearances of your result. Counting rules depend on the result type. | That someone carefully read your listing. | | Average CTR | Clicks divided by impressions, expressed as a percentage. | Whether your content or business is successful on its own. | | Average position | The average position of the topmost result for the property or grouping being measured. | A fixed ranking that everyone sees. | These definitions follow Google's [Performance report overview](https://support.google.com/webmasters/answer/7576553). For example, 60 clicks from 3,000 impressions produces a CTR of **60 ÷ 3,000 × 100 = 2%**. Those are invented numbers, not an industry benchmark or a result from this website. A useful reading habit: say “this page received 60 recorded search clicks in the selected period,” not “60 people visited the website.” The second statement changes both the unit and the scope. ### Why Average Position Isn't Your Website's Rank A property-level average mixes many searches. If two results from your site appear in one search, Google uses the topmost position for the property's position calculation. Different search features also have different counting rules. Google's [clicks, impressions and position documentation](https://support.google.com/webmasters/answer/7042828) explains those details. Consider this deliberately simplified, hypothetical example. In the first period, your only 100 impressions are at position 3. In the next period, those 100 appearances remain at position 3, and you gain another 100 at position 15 for new searches. The average moves from 3 to 9: `((100 × 3) + (100 × 15)) ÷ 200`. The average looks worse, but nothing in this example lost its old position. Your visibility expanded. Real reports contain more variation, but the lesson holds: before rewriting a page because its average changed, check which queries and pages entered the mix. Use position as a diagnostic clue alongside clicks and impressions. A filtered query-and-page trend is usually more useful than a single site-wide number. It still represents an average, not a promise about the result you'll see in a manual search. ### Set Up a Fair Comparison First Before interpreting the chart, make the comparison repeatable: 1. **Confirm the property.** Check that you're looking at the intended domain or URL-prefix property, especially if you manage multiple sites. 2. **Keep the search type consistent.** Start with Web for an ordinary website review. Don't compare one period's Web results with another period's Image results. 3. **Compare equal periods.** Use the date comparison control. Two complete 28-day periods are a practical starting point because they contain the same weekday mix, not because 28 days is a Google requirement. 4. **Record active filters.** A page, query, country or device filter can explain an apparently missing chunk of traffic. Clear old filters before beginning a different question. Google's [filtering and comparison instructions](https://support.google.com/webmasters/answer/17011165) cover those controls. For a seasonal business, also compare a similar season when you have enough history. A winter service shouldn't be judged only against summer demand. Use completed days for routine decisions. The freshest figures can be preliminary and change as processing continues; Google distinguishes that data in its [report data notes](https://support.google.com/webmasters/answer/17011364). A quiet morning isn't evidence that yesterday's page edit failed. ### Move from the Whole Site to One Useful Question Start with the Pages table. Choose a page that matters to the business, apply its page filter, then open Queries. You're now asking: “What searches brought this particular page into results?” That's a more actionable question than “How is our SEO doing?” Read the visible queries for meaning, not just volume. For a consultancy's service page, “technical SEO audit cost” and “what is SEO” suggest different needs. The first may call for clearer buying information; the second may belong in an educational guide. Use our [search intent guide](https://ivig.dev/search-intent-guide/) before assuming both should lead to the same content. Next, split by device or country only when it helps answer the question. A mobile decline might deserve a mobile-page check. A country difference might reflect an audience you don't serve. Avoid slicing a small dataset until every row contains one impression. It can also help to separate searches containing your brand from other searches. A simple query filter can create a useful subset, but aliases and spelling variations need thought. Some properties have a branded-query filter; availability and classification aren't universal. Google's [dimension documentation](https://support.google.com/webmasters/answer/17011259) explains the limitations. Don't turn every query into a new article. If several searches ask the same underlying question, improving one suitable page may be the better decision. The [keyword research guide](https://ivig.dev/keyword-research-guide/) explains how to group topics and map them to pages. ### Three Patterns Worth Investigating #### 1. Impressions rise, CTR falls, clicks rise Here's another hypothetical example, using the same report scope in both periods: | Period | Impressions | Clicks | CTR | | --- | --- | --- | --- | | Earlier | 3,000 | 60 | 2% | | Later | 6,000 | 90 | 1.5% | Clicks increased by 50%, even though CTR fell by 0.5 percentage points. First inspect the new query and page mix. Broader visibility could explain the change. Then ask whether the extra clicks reach useful pages and lead to appropriate next steps. Neither “CTR down” nor “clicks up” is a complete business verdict. #### 2. Impressions and clicks fall together Find where the loss is concentrated before deciding on a fix. Is it one URL, a whole directory, a device group or most of the site? Compare the timing with known site changes and seasonal demand. Google's [traffic-drop guide](https://developers.google.com/search/docs/monitor-debug/debugging-search-traffic-drops) covers technical issues, changing demand, ranking changes and reporting anomalies as possible causes. My first task would be to list the affected pages and dates. If an important page also fails to open or has an unexpected indexing status, investigate that evidence with the [indexing troubleshooting guide](https://ivig.dev/page-not-indexed/). A chart shape alone doesn't identify the cause. #### 3. CTR falls while the comparable slice looks similar If the same page and query group has broadly similar impressions and position, review how the page is presented and whether it still answers the search need. Check the visible search result as a snapshot, not a definitive reproduction of everyone else's results. A title experiment might be reasonable if the existing title is vague. Write down the problem, proposed change and review period first. Keep the title accurate; promising something the page doesn't deliver isn't a useful test. See the [on-page meta tag guide](https://ivig.dev/on-page-seo-guide/) for implementation. ### Why the Numbers Don't Always Match **Query rows aren't a complete search log.** Privacy-protected queries are omitted from the table, and other reporting limits can hide rows. Some hidden-query data can remain in chart totals, but applying a query filter changes what's included. Most performance data is attributed to Google's chosen canonical URL. These are documented [reporting behaviors](https://support.google.com/webmasters/answer/17011259), not evidence that an export is broken. **Chart totals and table sums can measure different groupings.** Property-level aggregation and page-level aggregation aren't interchangeable. Exported visible rows shouldn't be treated as a complete ledger you can always reconcile to the headline chart. **Search Console clicks won't necessarily equal GA4 organic sessions.** The tools measure different events and use different processing rules. Consent, JavaScript tracking, time zones and channel scope can also affect a comparison. Google's [data-discrepancy notes](https://support.google.com/webmasters/answer/17010575) explain common reasons. Don't force agreement by changing tags without diagnosing the difference. Use Search Console to study Google Search visibility and clicks. Use properly configured analytics to examine behavior after arrival and meaningful actions. Our [GA4 setup guide](https://ivig.dev/ga4-setup-guide/) covers that separate measurement job. ### A Small Review Routine You Can Repeat Set aside a short, regular review and leave with one decision, not a long list of unexplained percentages: 1. **Save the scope:** property, dates, search type and filters. 2. **Find one meaningful change:** a page with lost clicks, new relevant queries or a persistent mismatch between intent and content. 3. **Check an alternative explanation:** seasonality, query mix, recent deployment or a reporting difference. 4. **Choose a proportionate action:** inspect a broken URL, clarify an answer, improve a relevant internal link, or deliberately make no change. 5. **Log what happens next:** URL, evidence, hypothesis, edit date and when you'll review comparable data again. For a new site with little data, the sensible outcome may be “keep publishing useful material and collecting a baseline.” One click becoming two is a 100% increase, but not strong evidence of a repeatable improvement. You can still check important URLs, site navigation and whether each page serves a clear need. For a broader investigation, use the [SEO audit checklist](https://ivig.dev/seo-audit-checklist/). Performance data helps prioritize questions; it doesn't replace inspecting the website. ### Need Help Deciding What to Investigate? I offer a free initial review of a small selection of public pages, with up to five priority findings or next steps by email. It's not a comprehensive audit. Search Console analysis, a multilingual crawl or implementation would need a separate agreed scope and any necessary access. [Request a free website review](https://ivig.dev/#free-audit) ### Frequently Asked Questions **What is a good CTR in Google Search Console?** There is no single target that makes sense for every page. Compare a consistent page and query group over comparable periods, then consider position, intent, device and the mix of searches. A lower site-wide CTR alone is not a diagnosis. **Does average position tell me my exact Google ranking?** No. It summarizes recorded positions across the selected data. Different queries and audiences can produce different results, so use it as context alongside clicks and impressions rather than a fixed rank. **Why do query rows not add up to the chart total?** The table can omit privacy-protected queries and other rows. Filters and aggregation also affect totals. Do not assume the visible query table is a complete record of every impression. **Why are Search Console clicks different from GA4 sessions?** They measure different events. Tracking, consent, processing, time zones and the scope of organic channels can also differ. Investigate the measurement setup before expecting the totals to match. **What should I do if my new site has very little data?** Keep checking important pages and building useful content while you collect a baseline. Avoid major changes based on a handful of impressions or clicks. Small counts can produce large percentage swings without a reliable trend. ### Where to Go Next - [Connect and verify your Search Console property](https://ivig.dev/google-search-console-setup/) if you haven't started collecting data. - [Turn relevant queries into a content plan](https://ivig.dev/keyword-research-guide/) without publishing a page for every keyword. - [Set up GA4 measurement](https://ivig.dev/ga4-setup-guide/) to study what visitors do after arriving. --- ## Guide: Hreflang Explained: International SEO Without the Common Mistakes URL: https://ivig.dev/hreflang-seo-guide/ Author: Milan Georgijevic Published: September 18, 2026 Separate language targeting from canonicalization, build a clear page-to-page map and follow a complete three-language HTML example. Includes a checklist for launch and future changes. **Hreflang is an annotation that connects equivalent pages for different languages or regions.** It helps Google understand which version is intended for which audience. It doesn't translate content, redirect visitors or make a weak page useful. If you run a single English-language website, international visitors alone aren't a reason to add it. Hreflang becomes relevant when you actually publish alternatives, such as English and Serbian versions of the same service page. This guide starts there, then walks through a small implementation you can check yourself. ### When Do You Need Hreflang? Think in terms of a visitor's choice. Is there another version of *this page* that serves the same purpose for a different language or regional audience? If yes, there's a relationship worth mapping. If not, adding language labels won't create one. | Situation | Practical starting point | | --- | --- | | One English site, worldwide readers | No alternate pages to connect. Don't manufacture hreflang entries. | | English and Serbian versions of each service | Map equivalent service URLs into language groups. | | Separate UK and US product pages | Review regional alternatives and their canonical strategy together. | | Only the navigation is translated | Review the actual content and user experience before calling it a translated page. | Google recommends separate URLs for language versions and determines page language from visible content. A translated menu around an otherwise untranslated article isn't the same as a useful translated article. Its [multilingual website guidance](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) explains the distinction. For a small business, translation maintenance matters as much as launch. Who will update the second version when the service, price or eligibility changes? It's better to publish a smaller set of maintained alternatives than to create a large collection of neglected copies. ### Hreflang, Canonical and HTML Lang Do Different Jobs - **Hreflang:** connects equivalent language or regional versions. - **Canonical:** indicates the preferred representative among duplicate or very similar URLs. - **HTML `lang`:** declares the language of a document or element, helping software such as screen readers pronounce it appropriately. [MDN's lang reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/lang) covers that third role. A German page can have ``, a canonical pointing to its own preferred address, and hreflang links to its English and Serbian equivalents. Those instructions aren't substitutes for each other. In the simple translated-page example below, each page self-canonicalizes. Don't canonicalize every translation to English: that asks Google to consolidate pages you're also trying to present as alternatives. Google's [canonical guidance](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) recommends a canonical in the same language when using hreflang, where one exists. Same-language regional duplicates need a more deliberate decision. Google discusses combining a preferred canonical with regional annotations in its [multi-regional guidance](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites). Don't apply the translated-page recipe blindly to ten nearly identical English country pages. First decide what each version genuinely offers. Our [canonical URL guide](https://ivig.dev/canonical-url-guide/) and [duplicate content guide](https://ivig.dev/duplicate-content-seo-guide/) explain the underlying choices. ### Map One Content Group Before Writing Tags The following URLs are fictional examples. Imagine three genuinely translated versions of an SEO audit service. They describe the same service and help readers complete the same task: | Audience | Code | Preferred URL | | --- | --- | --- | | English readers | `en` | `https://example.com/en/seo-audit/` | | German readers | `de` | `https://example.com/de/seo-audit/` | | Serbian readers | `sr` | `https://example.com/sr/seo-audit/` | A language code such as `en` doesn't restrict the page to one country. Add a region only when the page is intended for that regional audience: `en-GB` means English for the UK, while `en-US` means English for the US. Use `GB`, not `UK`; a country code alone isn't a language annotation. Check Google's [supported codes](https://developers.google.com/search/docs/specialty/international/localized-versions#language-codes) for language, region and script requirements. Build a separate group for your contact page, another for your pricing page, and so on. Don't connect every German URL to the English homepage. An alternate should help someone continue the same task in another language, not restart their journey. If only two versions of an article exist, that article's group has two versions. Leave a missing translation out until it is published. Don't invent a destination or use an unrelated page just to fill the same number of columns in every group. ### A Complete HTML Example For this small static-site example, use HTML annotations in the document's ``. Include fully qualified URLs, the page itself and its equivalents. Each version needs the corresponding return links. Google also accepts HTTP headers and XML sitemap annotations; choose one manageable method instead of maintaining three copies. See its [implementation reference](https://developers.google.com/search/docs/specialty/international/localized-versions). This is the relevant head markup for the **English** service page. Keep the rest of your normal head content, including its title and description. ```html ``` On the **German** page, the alternate set stays the same. The canonical changes to the German page: ```html ``` On the **Serbian** page, use its own canonical and the same alternate set: ```html ``` Replace the example domain and paths with your real mapped URLs. Don't paste these tags onto a website that has no corresponding translations. If you use a CMS, look for an existing language mapping feature before adding another plugin or a second set of tags. ### What Does X-Default Mean? `x-default` identifies a fallback when none of the listed language or regional choices matches. It is optional. Google's [x-default explanation](https://developers.google.com/search/blog/2023/05/x-default) describes using a language selector or another suitable default page. In this example, English is the business's chosen fallback, so the English service URL appears twice with different labels: `en` and `x-default`. That is intentional. It doesn't mean English has become a canonical for the other translations. It also doesn't implement a redirect. If you want people to choose a language, provide a visible switcher that works. Don't assume a search annotation will change the browser's page content or navigation. ### A Practical Pre-Publish Checklist Test one complete group before rolling the template out across the site. A syntax check on one page won't tell you whether the other destinations agree. 1. **Open every mapped URL.** Confirm the expected content, language and audience. An HTTP `200` response containing an error message isn't a successful translation. 2. **Check access and indexing intent.** These should be public pages intended for search, not login screens, staging pages or accidentally excluded URLs. Use our [technical SEO guide](https://ivig.dev/technical-seo-guide/) for those foundations. 3. **Inspect the delivered markup.** For this HTML method, check that the annotations are in the head, not displayed as text in the page body. Check for duplicate output from a theme and plugin. 4. **Compare the sets.** In our example, all three pages should show the same four language-to-URL pairs. Each should show its own preferred canonical. Check exact hosts, paths and trailing slashes. 5. **Follow the return relationship.** If English identifies German, confirm that German identifies English. Google's [explanation of missing return links](https://developers.google.com/search/blog/2014/07/troubleshooting-hreflang-annotations-in) describes why one-way annotations can fail; that historical post's reporting interface is not a current UI walkthrough. 6. **Try the language switcher.** Can a visitor choose an alternative and remain on the equivalent service or article? Google advises against forced language redirects in its [multilingual guidance](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites). Keep a compact test record: content group, expected URL pairs, actual canonical, status, missing return links and who owns the fix. For larger sites, have a crawler or script compare the complete mapping. A green check on a single URL doesn't establish that every group is correct. ### Keep the Mapping Correct After Launch Most avoidable problems start when the content changes but the mapping doesn't. Treat translations as related records, not strings scattered across templates. - **A translation moves:** update the group's stored destination and regenerate every member's annotations. Review the redirect separately; don't rely on an old URL remaining a useful destination indefinitely. - **A translation is removed:** remove its entry from the surviving members. Decide what its old URL should do based on whether a genuinely suitable replacement exists. - **A new language launches:** add it to the relevant groups only after the corresponding pages are ready. Test from old pages as well as new ones. - **A template changes:** sample a fully translated group, a partially translated group and a page with no alternatives. The last one is useful for catching accidental site-wide tags. After deployment, inspect representative URLs and their canonical information in Search Console. Language and country performance can provide context, but a country-filtered traffic chart isn't a hreflang validator: people in one country don't all use the same language. Use our [Search Console data guide](https://ivig.dev/google-search-console-performance-guide/) to avoid reading too much into those averages. If the wrong version continues to appear, inspect the content, URL access, canonical choice and mapping together. Adding more annotations without understanding the conflict can make maintenance harder. ### Planning or Troubleshooting a Multilingual Site? I offer a free initial review of a small selection of public pages, with up to five priority findings or next steps by email. It's not a comprehensive audit. Search Console analysis, a multilingual crawl or implementation would need a separate agreed scope and any necessary access. [Request a free website review](https://ivig.dev/#free-audit) ### Frequently Asked Questions **Does a single-language website need hreflang?** Not simply because it receives international visitors. First identify whether equivalent language or regional versions actually exist. If you publish just one version, there are no alternate pages to connect. **Is hreflang a meta tag?** In an HTML implementation, it is an attribute on a link element with rel="alternate", not a meta element. The example in this guide belongs in the document head. **Should all translations canonicalize to English?** Not in the translated-page example here. Each language page uses its own preferred canonical. Same-language regional duplicates require a separate assessment of which version should be preferred. **Does x-default automatically redirect visitors?** No. It identifies a fallback for search engines; it does not change browser navigation. Build a visible language selector or other appropriate navigation separately. **What if one page has no translation?** Leave missing alternatives out of that content group. Do not point to an unrelated page or invent a URL just to complete the set. Add a translation to the group when the corresponding page is ready. ### Where to Go Next - [Understand canonical URL signals](https://ivig.dev/canonical-url-guide/) before changing preferred versions. - [Review XML sitemap fundamentals](https://ivig.dev/xml-sitemap-guide/) if your platform manages language annotations there. - [Plan a broader technical and content audit](https://ivig.dev/seo-audit-checklist/) when multiple templates are involved. --- ## Guide: Duplicate Content and SEO: When It Matters and How to Fix It URL: https://ivig.dev/duplicate-content-seo-guide/ Author: Milan Georgijevic Published: 2026-09-16 Updated: 2026-09-19 If the pages are different but may target the same search need, investigate [keyword cannibalization](https://ivig.dev/keyword-cannibalization-guide/). Shared keywords alone do not prove that two pages should be consolidated. Duplicate content is the same, or substantially similar, main content available at more than one URL. It can happen within your own website or across different websites. It doesn't automatically mean someone copied an article: a tracking parameter, an old address or a second category path can create another version of the same page. The useful question isn't “How do I remove every repeated sentence?” It's “Do these URLs serve the same purpose, and which ones should people find in search?” This guide helps you answer that before you delete pages or change indexing settings. ### What Counts as Duplicate Content? Compare the main information and the task a page helps someone complete. These two example addresses could display exactly the same service page: - `https://example.com/seo-audit/` - `https://example.com/seo-audit/?utm_source=newsletter` The second address records where a visit came from. If it doesn't change the page's main content, it hasn't created a new service or a new article. Two addresses don't necessarily represent two different pieces of information. Near-duplicates aren't always identical word for word. A different headline or a few swapped adjectives might leave the substance unchanged. Conversely, two detailed guides can discuss the same broad subject while answering different questions. Google's [canonicalization documentation](https://developers.google.com/search/docs/crawling-indexing/canonicalization) explains that it groups pages with the same or very similar primary content and selects a representative URL. That selected address is called the canonical. If the terminology is new, our [beginner's technical SEO guide](https://ivig.dev/technical-seo-guide/) explains how this fits into crawling and indexing. ### Is There a Duplicate Content Penalty? Ordinary duplicate URLs aren't automatically a Google penalty. Google's [SEO Starter Guide](https://developers.google.com/search/docs/fundamentals/seo-starter-guide) distinguishes normal URL duplication from copying other people's content. Having the same page accessible through multiple addresses isn't, by itself, grounds for a manual action. That doesn't make every form of duplication harmless. Google's [spam policies](https://developers.google.com/search/docs/essentials/spam-policies) address practices such as abusive scraping and producing large amounts of unoriginal content mainly to manipulate rankings. Those are different from a shop generating a tracking URL for an existing product. For a legitimate website, the problems to investigate are usually more concrete: - The wrong address represents the content. Search visitors may reach an outdated or unintended version. - The website gives inconsistent clues. Navigation, sitemaps and page annotations can disagree about which address is preferred. - Maintenance becomes harder. Two live copies of a service description can drift apart when only one gets updated. - Generated URLs multiply unnecessarily. Large parameter combinations can consume crawling resources without adding useful content. Google discusses the crawling problem in its [URL structure guidance](https://developers.google.com/search/docs/crawling-indexing/url-structure). A handful of campaign URLs and an effectively endless set of filter combinations deserve different levels of attention. Don't turn a small duplication report into an emergency without checking its scope. ### Common Causes, and Things That Only Look Like Duplicates #### Tracking parameters and alternate paths A product might be reachable from both a sale category and a brand category using different addresses. Campaign parameters, session identifiers and inconsistent URL generation can add more variants. Check what each address actually returns; don't assume every question mark creates a duplicate. #### Old URLs and inconsistent site versions After a redesign, an old service URL may still display the same content as its replacement. HTTP and HTTPS, www and non-www, or slash and non-slash versions can also expose copies if the site serves them separately. Changing the visible menu doesn't necessarily retire the old route. #### Repeated templates, titles and descriptions A shared header, footer or contact block doesn't mean every page is the same. Likewise, a crawler warning about duplicate titles is a metadata finding, not proof that the main content is duplicated. Review those issues separately. Our [on-page SEO guide](https://ivig.dev/on-page-seo-guide/) covers page titles and descriptions. For example, an audit service page and an audit tutorial can share your navigation and author biography while serving different needs. Explain what the customer receives on the service page; teach the process on the tutorial. You don't need to invent a new footer for each one. #### Pagination and genuinely different selections Page two of a product category normally shows different items from page one. It isn't a duplicate just because the layout matches. Google's [pagination guidance](https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading) recommends a separate URL and canonical for each page, rather than pointing every page to the first. Filters need a deliberate content and crawl strategy. Before deciding to keep a filtered landing page in search, ask whether it has a stable purpose and a useful selection for a specific audience. Don't apply the same rule to a valuable category and every possible sorting combination. #### Translations and overlapping topics Properly translated main content isn't treated as a duplicate merely because it conveys the same information in another language. Google's [canonicalization guidance](https://developers.google.com/search/docs/crawling-indexing/canonicalization) distinguishes translated primary content from pages where only navigation has been translated. International targeting needs its own review. Two articles sharing a keyword aren't automatically duplicates either. A guide to choosing an audit provider and a checklist for conducting an audit can have distinct jobs. Use [search intent](https://ivig.dev/search-intent-guide/) to examine the purpose before combining them. ### How to Investigate a Suspected Duplicate Start with a small group of URLs that a tool or report flagged. Save the examples before making changes. My suggested review sheet has five fields: URL, page purpose, main-content comparison, reported canonical and proposed action. - Open the pages side by side. Compare the actual service, products, instructions or answers. Look past navigation and other repeated layout elements. - Check their behavior. Does each URL show a page, redirect somewhere else or return an error? Note the final address and HTTP response. The [status code guide](https://ivig.dev/http-status-codes-guide/) explains those responses. - Inspect the declared canonical. Record the preferred address stated by each page, including any unexpected domain or hard-coded destination. - Compare Google's stored information. In Search Console, inspect the affected URL and its reported canonical. The [URL Inspection documentation](https://support.google.com/webmasters/answer/9012289) explains why indexed information and a live test are different; the live test cannot predict Google's canonical choice. - Find the source of the extra URL. Check menus, category templates, internal links, sitemap entries and CMS routing. Fixing the generator is often more useful than editing each resulting URL. #### What the Search Console messages mean Google's [Page indexing report](https://support.google.com/webmasters/answer/7440203) distinguishes several situations: - Alternate page with proper canonical tag: Google recognizes an alternative version pointing to an indexed representative. If that matches your intention, there may be nothing to fix. - Duplicate without user-selected canonical: Google selected a representative without an explicit preference from this page. Check whether that choice is suitable. - Duplicate, Google chose different canonical than user: your preferred address and Google's selection differ. Compare the content and technical signals before changing settings. The goal isn't to make every discovered URL indexed. It's to make the intended, useful pages available in search. If the preferred page itself is missing, continue with our [indexing troubleshooting guide](https://ivig.dev/page-not-indexed/). ### Should You Keep, Merge, Redirect or Canonicalize? Make the editorial decision first: do visitors need both pages? Then choose the technical behavior. This table is a starting point, not a rule to apply blindly across a website. | Situation | Starting action | Check before release | | --- | --- | --- | | Different useful purposes | Keep both and make their roles clear. | Each page delivers its own answer or task. | | Two overlapping articles | Consider merging useful material. | The combined page preserves what readers need. | | An obsolete equivalent URL | Use a permanent redirect. | The destination genuinely replaces the old page. | | A needed duplicate version | Suggest the representative with a canonical. | The pages are equivalent and the target works. | | A public page unwanted in search | Consider noindex for that goal. | It should be excluded, not consolidated. | #### Keep pages when their value is genuinely different If both pages deserve to exist, improve the actual information that distinguishes them. Add relevant examples, product details, scope or answers. Swapping synonyms to make a similarity score smaller doesn't help a reader choose the right page. Google's [canonical troubleshooting guidance](https://developers.google.com/search/docs/crawling-indexing/canonicalization-troubleshooting) recommends checking technical errors and whether pages grouped together have sufficiently different content. A self-referencing tag alone doesn't explain why an otherwise identical page should be treated separately. #### Merge overlapping material, then retire the redundant URL For two guides serving the same audience and task, review what each contributes before combining them. Choose the destination using relevance, existing links, search data and maintenance needs, not simply whichever URL looks shorter. Preserve useful material and update links that point to the retired page. Use a permanent redirect when the move really is permanent. Google's [redirect documentation](https://developers.google.com/search/docs/crawling-indexing/301-redirects) lists server-side `301` and `308` responses for that purpose. A redirect changes the destination for visitors too. Don't send unrelated removed pages to the homepage merely to avoid seeing errors. #### Use a canonical when equivalent versions must stay accessible A canonical annotation suggests which equivalent URL should represent the content while leaving the other version available. It isn't a browser redirect or a guarantee that Google will accept the choice. Follow Google's [canonical implementation guidance](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls), and use our [canonical URL guide](https://ivig.dev/canonical-url-guide/) for the HTML and testing details. Make supporting signals consistent: use the preferred address in internal links and the sitemap, and avoid conflicting annotations. Don't point a genuinely different service at a popular article simply because you'd like the article to rank better. #### Use noindex only when exclusion is the goal `Noindex` asks Google to keep a page out of search. It isn't a way to nominate another page as its representative. For example, a public utility page might need to remain usable without becoming a search landing page. Google must be able to crawl the page to see its [noindex directive](https://developers.google.com/search/docs/crawling-indexing/block-indexing). A robots.txt block can prevent that. Don't combine controls without understanding their different jobs, and don't treat noindex as password protection. Our [robots.txt guide](https://ivig.dev/robots-txt-guide/) explains crawl control separately. ### A Worked Example: Two Guides Answering the Same Question This is a hypothetical example, not a client result. A consultancy has an older article called “Website Audit Steps” and a newer one called “How to Audit Your Website.” Both walk beginners through essentially the same process. The older page contains a useful evidence-recording example; the newer one has a clearer checklist. My first recommendation would be an editorial review, not an immediate canonical change: - Check whether either article serves a distinct audience or receives searches for a different task. - If they really overlap, choose one destination and combine the useful example with the clearer checklist. - Redirect the retired article to the finished replacement, then update relevant internal links and the sitemap. - Check the live redirect, destination content and subsequent Search Console information. If the review instead shows that one page helps a business hire an auditor and the other teaches a developer how to run checks, keeping both may be the better decision. Their shared vocabulary isn't the deciding factor. For translated or regional alternatives, read the [hreflang guide](https://ivig.dev/hreflang-seo-guide/) before changing canonical signals. ### How to Check Whether the Fix Worked Separate what you can verify immediately from what requires a later search-engine visit. Record the release date and keep a rollback path for changes to templates or routing. - Immediately: open the old and preferred URLs, test redirects, inspect canonical and robots directives, and confirm the destination still contains the expected information. - Across the site: sample other pages using the same template. Confirm that [internal links](https://ivig.dev/internal-linking-seo-guide/) and the [XML sitemap](https://ivig.dev/xml-sitemap-guide/) reflect the intended page map. - After reprocessing: revisit indexed URL Inspection data and assess whether the reported representative matches your intention. Google needs time to reevaluate changed pages; don't promise a fixed recovery date. Keep business outcomes separate from implementation checks. A working redirect is something you can prove. More traffic or inquiries after consolidation is an outcome to measure, not a guaranteed reward. For larger patterns, use the [SEO audit checklist](https://ivig.dev/seo-audit-checklist/) to document affected pages, causes and priorities. ### Unsure Whether Your Pages Are Duplicates? I offer a free initial review of a small selection of public pages, with up to five priority findings or next steps by email. A detailed crawl, Search Console analysis or implementation would be a separate agreed scope. [Request a free website review](https://ivig.dev/#free-audit) ### Duplicate Content: Frequently Asked Questions **Does duplicate content automatically cause a Google penalty?** No. Ordinary duplication caused by multiple URLs isn't automatically a manual-action issue. Abusive scraping or producing unoriginal pages to manipulate rankings is a separate matter covered by Google's spam policies. **Are repeated headers and footers duplicate content?** A shared layout isn't enough to conclude that two pages are duplicates. Compare their main information and purpose. Keep navigation consistent and make each useful page's role clear. **Should I delete every page flagged as a duplicate?** No. Confirm the comparison, check whether visitors need both versions and identify the intended representative. Depending on the situation, you may keep the pages, combine useful material, redirect an obsolete address or annotate an equivalent version. **Is rewriting a few sentences enough?** Not necessarily. Cosmetic wording changes can leave the same underlying information and task. If both pages need to exist independently, explain their genuinely different value rather than writing to pass a similarity score. **Can two articles target related keywords?** Yes. Related vocabulary doesn't by itself prove duplication. Compare audience, search intent and what each page helps a reader accomplish before deciding whether to keep or combine them. Need to choose between keeping an alternate URL and moving its visitors? Read [Canonical Tag vs. 301 Redirect: Which Should You Use?](https://ivig.dev/canonical-vs-301-redirect/) for worked examples and a verification checklist. --- ## Guide: What Is Technical SEO? A Beginner's Guide to How Your Website Gets Found URL: https://ivig.dev/technical-seo-guide/ Author: Milan Georgijevic, Technical SEO Consultant Published: 2026-09-16 Technical SEO can sound like a job for developers only. This guide explains the foundations in plain language, shows what you can check yourself and helps you recognize when a problem needs specialist help. **Technical SEO is the work that helps search engines access, process and understand your website, while keeping its pages reliable and usable for people.** It covers things such as crawling, indexing controls, internal links, redirects, duplicate URLs and page performance. You don't need to become a developer to understand it. You do need to separate three questions: can Google reach this page, can it consider the page for its index, and does the page deserve to appear for a particular search? Those aren't the same problem. ### What Does Technical SEO Actually Do? Imagine publishing a useful guide and then accidentally telling search engines not to index it. Improving the headline won't solve that instruction. Equally, removing the instruction won't turn an unhelpful article into a good answer. Technical SEO deals with the website conditions around your content; content work deals with whether that content is worth finding. Google's [minimum technical requirements](https://developers.google.com/search/docs/essentials/technical) include access for Googlebot, a working page returning HTTP `200`, and indexable content. Meeting those requirements makes a page eligible for indexing. It doesn't guarantee inclusion or a particular position. - **Crawlable:** a search engine can request the page and retrieve its resources. - **Indexable:** the page is technically eligible to be considered for the search index. - **Indexed:** the search engine has included the page in its index. - **Ranking:** an indexed page is selected and ordered for a particular query. This is why “the page opens in my browser” isn't a complete SEO test. Your browser visit doesn't tell you which URL Google selected, whether it encountered an indexing restriction, or what happened on its last visit. For the underlying process, read [how Google Search works](https://ivig.dev/how-google-search-works/). ### Technical SEO vs. On-Page SEO vs. Off-Page SEO These labels describe useful areas of work, not perfectly separate departments. An internal link helps a reader navigate and helps a crawler discover a page. A page template can affect both headings and loading speed. | Area | Main question | Example task | | --- | --- | --- | | Technical SEO | Can the site be accessed, processed and used as intended? | Find an accidental indexing restriction on service pages. | | On-page and content SEO | Does this page clearly answer the audience's need? | Explain a service, improve its title and answer buying questions. | | Off-page SEO | How does the wider web reference and discover the business? | Earn a relevant editorial mention through useful original work. | A practical starting point is to pair technical checks with [search intent](https://ivig.dev/search-intent-guide/) and [clear on-page information](https://ivig.dev/on-page-seo-guide/). If a service page is accessible but never explains who the service is for, the next task probably isn't another server setting. ### The Main Areas Technical SEO Covers #### 1. Discovery and crawling Important pages need routes into them. Navigation, category pages and relevant links within articles can provide those routes. Google's [link guidance](https://developers.google.com/search/docs/crawling-indexing/links-crawlable) recommends standard HTML links with a destination in the `href` attribute and descriptive link text. An XML sitemap supplies another list of URLs you want discovered. It doesn't replace a sensible site structure, and [submitting one doesn't guarantee crawling or indexing](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview). Start with our [internal linking guide](https://ivig.dev/internal-linking-seo-guide/) and [sitemap guide](https://ivig.dev/xml-sitemap-guide/) if you need to improve those paths. #### 2. Rendering and indexing controls Rendering means processing a page into the content and layout a browser can display. On a JavaScript-driven website, some main content might appear only after scripts run. Google can render JavaScript, but resources blocked from crawling can prevent it from seeing the intended result. Google's [JavaScript SEO documentation](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) explains that distinction. Using JavaScript isn't automatically an SEO problem. Indexing controls are a separate concern. A `noindex` directive tells Google not to index a page. A `robots.txt` rule controls crawling. If you block crawling, Google may not be able to read the page's `noindex` directive. Google's [noindex documentation](https://developers.google.com/search/docs/crawling-indexing/block-indexing) explains why the two aren't interchangeable. Don't remove restrictions everywhere just because you want more traffic. Some pages intentionally stay out of search. Read the [robots.txt guide](https://ivig.dev/robots-txt-guide/) before changing crawl rules, and use the [page-not-indexed guide](https://ivig.dev/page-not-indexed/) to investigate a specific URL. #### 3. Preferred URLs and redirects The same content can exist at several addresses, such as a clean product URL and a version with tracking parameters. Canonicalization is the process of selecting a representative URL from duplicate or very similar pages. A `rel="canonical"` link indicates your preferred version. It doesn't redirect visitors, and Google can select a different canonical. Redirects move users and crawlers to another address. Google's [canonical guidance](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) describes redirects and canonical annotations as strong signals, with sitemap inclusion a weaker signal. The practical goal is consistency: navigation, internal links and the sitemap should support the URLs you actually want people to use. Our [canonical URL guide](https://ivig.dev/canonical-url-guide/) and [HTTP status code guide](https://ivig.dev/http-status-codes-guide/) cover implementation. Don't point distinct, useful pages at the homepage simply to clear a warning. #### 4. Performance and mobile usability A page can be available to a crawler yet frustrating to a person. Slow main content, a button that reacts late, or a layout that jumps while someone is reading can all deserve attention. [Core Web Vitals](https://developers.google.com/search/docs/appearance/core-web-vitals) measure loading performance, responsiveness and visual stability through LCP, INP and CLS. Use them to investigate specific user-experience problems, alongside real checks of navigation, text, images and forms on a phone. Google says good scores [don't guarantee top rankings](https://developers.google.com/search/docs/appearance/page-experience). Getting a perfect tool score isn't the goal. The [Core Web Vitals guide](https://ivig.dev/core-web-vitals-guide/) explains how to separate real-user measurements from diagnostic lab tests. #### 5. Structured data Structured data is machine-readable information about what a page contains, such as an article and its author. Google's [structured data introduction](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) explains how it can help interpret content and enable supported search appearances. It isn't a substitute for visible information, and it won't rescue a blocked page. Choose markup that accurately describes the page rather than adding every type a plugin offers. See the [schema markup guide](https://ivig.dev/schema-markup-guide/) for examples and validation. ### Your First Five Technical SEO Checks You can make this first pass without editing code. Pick your homepage, one important service or product page, and one article. Record the URL, what you expected, what you observed and the date. Sampling different page types is more useful than repeatedly testing only the homepage. - **Follow the route a visitor would take.** Start at the homepage and navigate to each selected page. Can you find it through ordinary links? Does the address change unexpectedly? Note broken destinations and pages you can reach only by pasting a URL. - **Inspect the exact URL in Search Console.** Start with its indexed information and reported reason if it isn't indexed. Then use the live test when you need to check the current version. The [URL Inspection documentation](https://support.google.com/webmasters/answer/9012289) distinguishes stored indexing information from live-test results; a live test doesn't predict Google's selected canonical. - **Review restrictions and the preferred address.** Check whether an intended public page reports a crawl block, a `noindex` instruction or a different canonical. Record the evidence before changing anything. A different canonical can be correct for a genuine duplicate. - **Check the sitemap and its purpose.** Confirm that it contains your selected preferred URLs where appropriate, and that listed pages open as expected. Investigate stale or unintended addresses instead of trying to make the file as large as possible. - **Use the pages on mobile and run a performance test.** Read the main content, open the menu and try the important controls. Use [PageSpeed Insights](https://pagespeed.web.dev/) for clues about performance, not a pass-or-fail verdict on your whole SEO strategy. If Search Console isn't connected yet, follow the [setup walkthrough](https://ivig.dev/google-search-console-setup/). Without access, you can still review public pages, navigation and performance, but you can't reliably infer Google's stored indexing details from what your browser shows. ### A Practical Example: A Service Page After a Redesign **This is a hypothetical example, not a client result.** A small consultancy redesigns its site. Its main service page opens normally, looks good on mobile and has clear copy, but Search Console reports that an indexing directive excludes it. The developer discovers that a setting used to keep the staging site out of search was copied into the live service-page template. The right response is narrow and testable: - Confirm that the live service page is intended for public search, and identify which templates share the setting. - Remove the unintended directive from those live pages, while preserving intentional restrictions elsewhere. - Check the HTML and response headers after deployment, then test the affected URLs again. - Monitor subsequent Search Console information to see whether Google has processed the change. The verified outcome is that the unintended restriction has been removed. Indexing and search performance still need observation. Rewriting every page or buying links wouldn't have addressed the original fault. ### What Should You Fix First? Prioritize a confirmed problem on an important page over a vague warning on an irrelevant URL. Ask what the issue prevents, how many useful pages it affects, how confident you are in the cause, and what could break when you change it. - **First:** unavailable important pages, accidental indexing restrictions and broken paths that stop people reaching the content they need. - **Next:** conflicting URL signals, recurring template problems and significant performance or mobile usability issues. - **Then:** useful refinements to markup, navigation and page presentation, based on the site's needs. This is a starting order, not a universal severity scale. A navigation defect across every product page can matter more than a restriction on an intentionally private page. Not every excluded URL is an error, and not every warning needs a fix. **Two common distractions:** chasing a perfect SEO score and treating crawl budget as every small site's biggest problem. Google's [crawl-budget guidance](https://developers.google.com/crawling/docs/crawl-budget) mainly addresses very large or frequently updated sites and particular discovery problems. A small site should establish basic access, sensible links and intended indexing before assuming it needs advanced crawl optimization. For a full investigation rather than this beginner's overview, use the [step-by-step SEO audit checklist](https://ivig.dev/seo-audit-checklist/). It shows how to turn observations into evidence, priorities and a repair plan. ### Can You Do Technical SEO Yourself? You can learn the concepts, check important pages, read reports and document issues without writing code. Some CMS settings and content-level links are also manageable once you understand their purpose. Bring in a developer or technical SEO specialist when a change affects server rules, shared templates, rendering, large-scale redirects or many URLs at once. Ask for a clear explanation of the problem, affected pages, proposed change and validation method. “Improve technical SEO” isn't a useful implementation brief. Before a meaningful change, keep a backup, test safely where possible and record what was released. Afterwards, validate the changed behavior before judging traffic. An SEO plugin can expose settings, but installing one doesn't establish that those settings are right for your site. ### Not Sure Which Technical Issues Matter on Your Site? I offer a free initial review of a small selection of public pages, with up to five priority findings or next steps by email. It's not a comprehensive audit. If you need deeper investigation or implementation, we'll agree on a separate scope first. [Request a free website review](https://ivig.dev/#free-audit) ### Technical SEO: Frequently Asked Questions **What is technical SEO in simple terms?** Technical SEO means improving how a website can be accessed, processed and understood by search engines, and how reliably people can use it. It includes crawling, indexing controls, URL handling, internal links and performance. **Is technical SEO the same as on-page SEO?** No, although they overlap. Technical SEO focuses on website behavior and access. On-page SEO focuses on the information and signals on individual pages, such as useful content, titles and headings. Internal linking can support both. **Do I need coding skills to get started?** No. You can inspect pages, follow navigation, use Search Console and document problems without coding. Changes to templates, server rules or rendering may need a developer, especially when many pages are affected. **Does a static website still need technical SEO?** Yes. Static HTML doesn't automatically ensure correct indexing instructions, canonical URLs, redirects, internal links or usable mobile pages. Review those foundations even when your site doesn't depend on JavaScript to display its main content. **Will fixing technical issues guarantee higher rankings?** No. You can verify that a technical problem has been fixed, but search performance also depends on relevance, content, competition and search engine decisions. A working, indexable page is a foundation, not a ranking promise. ### Where to Go Next - [Understand crawling, indexing and ranking](https://ivig.dev/how-google-search-works/) if the search process is still unfamiliar. - [Diagnose a page that isn't indexed](https://ivig.dev/page-not-indexed/) if you have a specific missing URL. - [Work through a complete SEO audit](https://ivig.dev/seo-audit-checklist/) when you're ready for a broader review. Related reading: [Duplicate Content and SEO: When It Matters and How to Fix It](https://ivig.dev/duplicate-content-seo-guide/). --- ## Guide: SEO Audit Checklist: How to Audit a Website Step by Step URL: https://ivig.dev/seo-audit-checklist/ Author: Milan Georgijevic, Technical SEO Consultant Published: 2026-08-28 An SEO audit is a structured investigation of how a website can be discovered, crawled, rendered, indexed, understood and chosen in search. It combines technical evidence, search performance, content review and business context. The deliverable is not the crawl itself. It is a defensible, prioritized repair plan. Google Search Essentials separate technical eligibility, spam policies and practices that can improve search appearance. An audit should do the same: confirm access and eligibility first, then investigate quality, relevance, experience and competitive opportunity. ### What a useful SEO audit produces - Reproducible evidence - Affected templates and URL groups - A cause, not only a symptom - Impact tied to real user and business goals - A practical owner and fix - A method for validating the change A weak audit is an unfiltered list of warnings, a score with no business meaning or recommendations applied without context. The goal is not a perfect site. It is a site where important pages are technically eligible, useful and supported by clear signals. ### Step 1: Define scope and baselines Write down why the audit exists. A migration loss, new launch, indexation problem and general growth review require different evidence. - Define domains, subdomains, protocols, markets, languages and environments in scope. - Identify priority revenue pages, lead pages, templates and recent releases. - Record migrations, redesigns, CMS changes, security events and major content work. - Choose comparison periods that account for seasonality and reporting delays. - Define success in measurable business and search terms. Capture a baseline before changing anything: clicks, impressions, conversions, intended indexed page patterns, Core Web Vitals groups and representative crawl results. Save the date and data source. ### Step 2: Gather evidence and tools Use the smallest toolset that answers the audit question: - A browser and developer tools for final URLs, rendered content, requests, errors and mobile use - Google Search Console for performance, indexing, sitemaps, URL Inspection, enhancements, manual actions and security issues - Analytics and conversion data, with consent and tracking gaps documented - A site crawler for internal URLs, status codes, directives, canonicals, headings, links and templates - PageSpeed Insights and browser performance tools - CMS, deployment history and server logs when public evidence is not enough Confirm that every data source covers the same site version. Search Console properties can omit protocols or subdomains. Analytics can undercount. Crawl data is a snapshot, while Search Console reports describe what Google observed over time. Build a representative URL set before crawling everything. Include each template, strong organic landing pages, conversion pages, changed pages, filters, pagination, redirects and known problem cases. ### Step 3: Check urgent visibility and safety risks Start with failures that can affect the whole property: 1. Open the site anonymously and check HTTPS, redirects, login walls and downtime. 2. Review Search Console messages, Manual Actions and Security Issues. 3. Check for accidental site-wide noindex, robots rules or canonicals pointing elsewhere. 4. Review recent deployments for template-wide changes. 5. Confirm that analytics and conversion measurement still work. Security and manual-action findings need different owners and urgency from routine SEO recommendations. Do not include sensitive exploit details in a broadly shared report. ### Step 4: Audit discovery, crawling and rendering Important pages need crawlable internal links and intentional sitemap coverage. Review orphan pages, pagination, categories, filters and routes created by parameters. Check robots.txt without confusing crawl control with index control. Classify HTTP responses by intent: important live pages generally return 200, redirects reach one relevant destination, removed pages have a deliberate response, and server errors are investigated across templates. For JavaScript sites, compare initial HTML, rendered DOM and Google's rendered view. Primary content, links, headings, canonicals and structured data should not depend on a failing interaction or blocked request. Use server logs when the question is whether and how Googlebot requested URLs. ### Step 5: Audit indexing and canonical control Define which URL types should and should not be indexed. Compare that intent with Search Console's Page indexing report, then use URL Inspection for representative examples. Inspect crawl permission, fetch result, indexing permission, user canonical, Google-selected canonical, discovery source and last crawl. Test live after changes, while remembering that the live test does not evaluate every indexing condition. Align redirects, canonical tags, HTTP headers, internal links and sitemaps around the preferred URL. Do not aim to index every discovered URL. Focus on mismatches: important pages excluded for the wrong reason, or low-value patterns consuming crawl and review effort. ### Step 6: Review architecture and internal links Trace real user journeys from broad hubs to useful details and next actions. Find orphan and unnecessarily deep pages. Review anchor text in context. Compare page importance with navigation, breadcrumbs, hubs and contextual links. Update broken or redirected internal links and group findings by component or template so the source can be fixed once. ### Step 7: Review content, intent and on-page signals For each important URL: 1. State the audience, task and successful outcome. 2. Identify overlapping pages by task, not vocabulary alone. 3. Review useful evidence, examples, policies, product details and decision support. 4. Find stale or unsupported claims. 5. Check titles and headings for clarity and template duplication. 6. Review descriptions, images and meaningful alt text. Do not grade content by word count. A short service page can be complete, while a long article can avoid the actual question. Review performance by page group and intent, and distinguish technical changes from demand, competitor and result-layout changes. ### Step 8: Check performance and mobile experience Start with real-user evidence in Search Console's Core Web Vitals report when data exists. Use lab tests to identify the element, request or main-thread work behind an issue. Test representative templates, not only the homepage. On mobile, review width, tap targets, sticky elements, overlays, menus and forms. Check keyboard use, focus, labels, contrast and headings. Review tags, chat tools, ads, consent systems and embeds that delay content or block interaction. Connect every recommendation to a specific template, resource and user impact. “Improve page speed” is not an implementable finding. ### Step 9: Check structured data and search appearance Validate supported structured data and review Search Console enhancement reports. Markup must describe visible content, use current supported types and never invent ratings, prices, authors or dates. Valid markup creates eligibility, not a guaranteed rich result. Review titles, headings, primary content, favicons and snippets together. A rewritten title is a reason to review clarity and consistency, not proof that one tag is broken. ### Step 10: Prioritize and report Each finding should include: - Finding: one plain-language problem - Scope: affected URL, template, directory or market - Evidence: reproducible steps, exports, responses or rendered output - Cause: confirmed implementation or clearly labeled hypothesis - Impact: what the issue prevents for users, search or conversion - Recommendation: the desired behavior and implementation detail - Validation: how to prove the fix before and after release Prioritize by likely impact, confidence, affected scope and implementation effort or risk. Sequence dependencies: access before indexing requests, canonical rules before sitemap cleanup, template defects before URL edits, and measurement before judging results. ### Complete checklist - Audit goal, boundaries, priority templates and success measures documented - Baseline search, conversion, indexing and performance evidence saved - HTTPS, availability, manual actions, security and site-wide directives checked - Important pages have crawlable discovery paths and intentional sitemap coverage - Robots rules, status codes, redirects, resources and rendering validated - Intended indexation compared with Page indexing and URL Inspection - Canonicals, redirects, internal links and sitemaps agree - Architecture supports key journeys without orphan pages - Priority pages have distinct intent, useful evidence and clear on-page signals - Mobile use, forms, consent, accessibility and Core Web Vitals sampled - Structured data represents visible content and passes current checks - Every recommendation has evidence, scope, impact, owner and validation ### FAQ **What is an SEO audit?** An evidence-based review of how a website can be discovered, crawled, rendered, indexed, understood and used, connected to a practical repair plan. **Can I do an SEO audit myself?** Yes. Site owners can check Search Console, crawl key paths, inspect URLs, review templates and test performance. Large or JavaScript-heavy sites may need logs, rendering tests and developer access. **What tools do I need?** Start with a browser, Search Console, analytics, PageSpeed Insights and a crawler. Add logs and specialist data only when the question requires them. **How often should a site be audited?** Audit after migrations, redesigns, platform changes or unexplained declines. Schedule broader maintenance according to release pace, size and risk instead of an arbitrary rule. **How long does an audit take?** It depends on size, templates, access and the questions being investigated. A focused small-site review can take hours; large ecommerce or JavaScript sites can require days. **What should the report include?** Scope, reproducible evidence, likely cause, user or search impact, recommended fix, owner, priority and validation method for every finding. --- ## Guide: Keyword Research for Beginners: How to Find Topics Worth Targeting URL: https://ivig.dev/keyword-research-guide/ Author: Milan Georgijevic, Technical SEO Consultant Published: 2026-08-27 Already have several pages answering the same need? Use the [keyword cannibalization workflow](https://ivig.dev/keyword-cannibalization-guide/) to check the evidence before merging them. Keyword research is the process of finding how people search for needs related to a subject, deciding which needs are worth serving and mapping each one to the right page. It connects audience research, content planning and search data. A keyword tool can supply ideas and estimates, but it cannot decide what a business should publish. A good outcome is not a spreadsheet containing thousands of phrases. It is a focused map: who is searching, what they want to accomplish, which topics matter, what page would help and why that version deserves to exist. ### Keywords, queries and topics A search query is the wording a person actually uses. A keyword is the phrase an SEO team uses to represent one or more related queries. A topic is the broader subject or problem those queries belong to. Queries can share vocabulary without asking for the same result. One may need an explanation, another a checklist, another pricing guidance and another a service. Keyword research has to identify both the common topic and the different tasks inside it. Google recommends anticipating the different words experienced and new users may search. Its language-matching systems can connect a page to queries even when every exact variation is not written on the page. The goal is one useful page per distinct audience task, not one page per phrase. ### Start before using a keyword tool Begin with products and services, customer problems, sales and support questions, jobs people complete, beginner and specialist vocabulary, locations, industries and use cases. Convert them into broad seed topics. For each seed, ask: What is it? How does it work? What problem does it solve? How do options compare? What could go wrong? What action follows? These questions reveal different informational, commercial and transactional needs. Avoid beginning with a competitor's full export, unrelated high-volume phrases, every trend, city-page permutations, separate pages for synonyms or unverified generated lists. ### Sources for keyword ideas 1. Search Console shows queries for which Google already displayed the site. Review impressions, clicks and CTR, then filter a query and switch to Pages to identify the URL shown. Look for relevant queries with impressions but weak clicks, rising topics and unexpected language. Search Console omits anonymized queries and does not list every row, so it is not a complete demand database. 2. Sales calls, support tickets, reviews and community discussions reveal the audience's actual symptoms, objections and vocabulary. Protect private information and summarize patterns. 3. Google autocomplete, related searches, visible result features and ranking pages can suggest wording, adjacent questions and expected formats. They do not provide reliable volume by themselves. 4. Google Keyword Planner expands words or websites and provides estimated searches and advertising data. Set location, language, network and date range correctly. Its Competition and bid columns describe advertising conditions, not organic ranking difficulty. 5. Google Trends helps compare wording, direction and seasonality. A search term measures specific wording while a topic groups searches around a concept. Trends values are normalized for the chosen time and place and scaled from 0 to 100; they are not absolute search volume. Low-volume terms may appear as zero. 6. Third-party SEO tools can find related phrases, questions, ranking pages and links. Their volume, traffic and difficulty values are modeled estimates. Competitor pages reveal coverage but should not be copied. ### Read keyword metrics correctly Search volume is an estimate of relative demand, not promised traffic. Trend data indicates direction and seasonality. CPC reflects advertising economics. Keyword difficulty is one tool's proprietary comparison, not a Google metric. Search Console impressions show that a result appeared for real searches. Current search results provide evidence about intent and competitors. A broad phrase with large volume can be ambiguous and unrelated to the offer. A small phrase can describe a valuable problem precisely. Low-volume and long-tail searches are not automatically easy, and broad topics are not automatically impossible. ### Group queries by intent Cluster phrases according to whether the same person, answer, format and next action would satisfy them. - Combine wording variations when they ask for the same outcome. - Separate ideas when the expected page, audience or action changes. - Keep local needs distinct when location changes availability or the result. - Use a hub when a broad seed contains several subtopics that each deserve depth. Do not create separate pages for singulars, plurals, word order or minor modifiers when one page can answer them naturally. ### Inspect the current search results Before approving a topic, check the dominant page type, angle, depth, result features, freshness and actual ranking pages. Compare usefulness, specificity, evidence, reputation and links. Identify what remains confusing, unsupported, stale or incomplete. Match the task rather than copying a competitor's outline. Shared result patterns reveal expectations, but the page still needs original experience, evidence, examples, clarity or utility. ### Choose topics worth targeting Score each candidate for: 1. Audience relevance 2. Intent and page-type fit 3. Business or organizational value 4. Distinct evidence or utility 5. Demand evidence 6. Feasibility and maintainability Use a simple red, amber and green assessment or a one-to-five scale, but do not let an average hide a fatal weakness. High demand cannot rescue an irrelevant topic, and a valuable idea may need to wait if the required evidence is unavailable. A worthwhile topic must be useful to the audience, lead to a meaningful outcome and be feasible to serve better or differently than available results. ### Map topics to pages Search the existing site before creating a URL. - Update an existing page when it already serves the task but lacks coverage, proof or clarity. - Create a new page when the task or ideal experience differs from every current URL. - Consolidate thin pages that compete for the same task. - Reject ideas that are irrelevant, unsupported or too weak. Record one intended owner for each cluster. A content map should include the topic, audience, primary task, related queries, intended page, page type, evidence, business goal, priority, status and related internal links. Two pages appearing for related queries do not automatically indicate cannibalization. The problem occurs when they serve the same task and send conflicting ownership signals. Consolidation should align redirects, canonicals, internal links and the sitemap. ### Complete workflow 1. Define the audience, market and goal. 2. List seed topics from offerings, problems, tasks, questions and use cases. 3. Collect first-party customer and query language. 4. Expand with Google results, Keyword Planner, Trends and a consistent SEO tool when useful. 5. Remove irrelevant ideas early. 6. Group phrases by audience task. 7. Review demand, trend, seasonality and location. 8. Inspect page types, formats, competitors and unresolved needs in the results. 9. Score relevance, intent fit, value, evidence, demand and feasibility. 10. Assign the cluster to an existing page, new page, consolidation or reject list. 11. Brief the required answer, proof, format, internal links and next step. 12. Publish, verify discovery and indexing, then learn from query and page performance. ### Common mistakes Starting with volume instead of the audience, creating one page per phrase, confusing advertising competition with organic difficulty, trusting one difficulty score, ignoring intent, copying a competitor's map, rejecting every zero-volume phrase, chasing unrelated trends, overlooking existing pages and never comparing the plan with real query data. ### FAQ **What is keyword research in SEO?** Discovering how people search, grouping queries by task, evaluating value and deciding which page should serve each useful topic. **What free tools can I use?** Search Console, Google Trends, Google Keyword Planner and the visible Google results each provide different evidence. **How many keywords should one page target?** There is no fixed number. One page can answer many variations of the same task; split when the intent, audience, format or next action differs. **Is search volume accurate?** It is an estimate. Use volume comparatively and check location, language, time range, seasonality and grouping rules. **Should I target zero-volume keywords?** Yes when the need is real and valuable. Tools can miss or group low-frequency searches, and a page can appear for many related queries. **What does keyword difficulty mean?** It is a proprietary tool estimate, not a Google score or verdict. Validate it against the actual results. Before prioritizing queries, use the [Search Console performance guide](https://ivig.dev/google-search-console-performance-guide/) to make fair comparisons and understand missing query data. --- ## Guide: Search Intent Explained: How to Create Content People Actually Want URL: https://ivig.dev/search-intent-guide/ Author: Milan Georgijevic, Technical SEO Consultant Published: 2026-08-16 Search intent is the task or outcome a person is trying to complete when they search. Keywords show the language used; intent describes the job behind that language. A query can ask for an explanation, a route to a known page, help comparing choices, an action such as buying or booking, or a mixture of those needs. A page can be crawlable, indexable and technically optimized but still be the wrong answer. A detailed article is unhelpful when the searcher needs a calculator. A product page is frustrating when the searcher wants an impartial comparison. A long introduction gets in the way when one direct fact would complete the task. ### Four practical search-intent types SEO teams commonly use four planning categories. They are useful shorthand, not an official set of Google ranking labels. 1. Informational: the searcher wants to learn, understand or solve something. Likely formats include guides, tutorials, definitions, videos, tools and documentation. 2. Navigational: the searcher wants a specific website, brand or page. Likely results include official homepages, login pages, branded sections and known tools. 3. Commercial investigation: the searcher is evaluating options before deciding. Useful pages include comparisons, reviews, alternatives, case studies and pricing explainers. 4. Transactional: the searcher is ready to complete an action. Useful pages include product, service, booking, signup and download pages. Commercial and transactional intent differ in the amount of uncertainty left. A comparison search still needs criteria and evidence. A query containing buy, book or download is closer to action and benefits from a direct path. ### Google's user-need language Google's public Search Quality Rater Guidelines use categories such as Know, Know Simple, Do, Website and Visit-in-Person. Know covers learning, Know Simple covers a concise factual answer, Do covers completing an activity, Website covers reaching a known site or page, and Visit-in-Person covers a nearby business, service or place. The familiar informational, navigational, commercial and transactional model is an SEO planning framework. Google's evaluator taxonomy is different, and both recognize that real queries can be ambiguous or have several reasonable intents. Quality raters do not control rankings and their individual ratings are not used directly to rank pages; their feedback helps Google evaluate search systems. ### Mixed and changing intent A broad brand query can mean visiting the website, shopping online, finding a nearby store, checking hours or reading news. A query such as broadway tickets can include both price research and a purchase goal. Results may contain several helpful page types because no one result satisfies every reasonable need. Intent can also change through a journey: learn about a problem, compare possible solutions, then act. A useful content architecture connects those stages with internal links instead of forcing one page to serve every need. Freshness, location, language, device and context can change the likely outcome. Query modifiers such as what, how, login, best, review, vs, price, buy, date, near me and model numbers narrow the task but should be treated as clues rather than absolute classification rules. ### How to identify search intent 1. Define the likely searcher and their level of knowledge. 2. Read the complete query literally, including its subject, verb, brand, place, date and qualifiers. 3. Mark useful modifiers without allowing one word to determine the classification. 4. Inspect current search results from the relevant country and device. Look for recurring page types, formats, result features, freshness and angles. 5. Write the primary task in one sentence. 6. List the information, proof or interaction required to complete that task. 7. Identify reasonable secondary intent without diluting the primary answer. 8. Validate the assumption with Search Console query and page data when it becomes available. Do not copy the top results. Use them to identify shared expectations and unresolved questions, then contribute clearer explanations, first-hand evidence, better examples, a useful tool or a more complete route to the outcome. ### Match the page type and format Choose the smallest experience that can satisfy the task well. A definition query may need a direct answer and essential context. A how-to needs ordered steps, prerequisites and checks. A comparison needs shared criteria and tradeoffs. A product query needs specifications, availability, price and a purchase path. A local query needs location, hours, service area and contact details. A diagnostic query needs a decision process and next actions. Format is part of the answer. Some tasks need video, images, an interactive input, a category or product interface rather than a conventional article. Google does not prescribe a preferred word count. Length should follow the complexity of the task. Titles, H1 headings, introductions and snippets should set the same expectation that the page fulfills. ### Map, split or combine pages Combine query variations when the same audience needs the same answer, page type and next step. Split pages when the audience, outcome or ideal experience changes. Use a hub when a broad topic contains several distinct tasks that deserve depth and navigation. Consolidate overlapping pages when they compete for the same need without providing meaningfully different value. Two URLs appearing for similar queries do not automatically indicate cannibalization. The key question is whether they satisfy distinct useful needs or create confusing duplication. A practical content map records one row per page: audience, primary task, page type, query cluster, proof required, intended next step and related pages. ### Measure the match No single metric proves satisfaction. Review Search Console queries and pages, click-through rate in the context of position and SERP features, page-specific engagement or completion, follow-up questions, and lead or sale quality. A high bounce rate can be a satisfied visitor who found a direct answer. A long session can be a confused visitor. Define success for the page before choosing a metric. ### Common mistakes Classifying intent from one modifier, presenting the four types as Google's algorithm labels, choosing a keyword without defining an audience or task, copying the current search results, ignoring mixed intent, writing a blog post for every need, forcing sales intent into informational pages, building separate pages for synonyms, using word count as a quality target, and never revisiting the original assumption. ### Publishing checklist Define the audience and primary task. Review complete query wording and secondary intents. Inspect current result types, formats and freshness. Choose a page type that can finish the task. Answer as early as complexity allows. Add original proof, examples or experience. Align the title, H1, introduction and next step. Connect distinct related needs through useful internal links. Choose behavior or business outcomes that can indicate success. ### FAQ **What is search intent in SEO?** The task or outcome a person is trying to complete with a query. **What are the four types of search intent?** SEO practitioners often use informational, navigational, commercial investigation and transactional as practical planning categories. **Is search intent a Google ranking factor?** Google evaluates relevance and helpfulness for queries, but it does not publish one factor or score called search intent. Matching a likely need is a content strategy, not a guarantee. **Can one keyword have multiple search intents?** Yes. Broad brand, product and topic queries often represent several reasonable needs. **How do I identify search intent?** Analyze the complete query, modifiers and current results, define the audience and desired outcome, then validate with real query and page data when available. **Should different intents have separate pages?** Split pages when audiences, outcomes or ideal formats differ meaningfully. Combine them when one focused page can complete the same primary task. --- ## Guide: Internal Linking for SEO: How to Build Links That Help Google and Users URL: https://ivig.dev/internal-linking-seo-guide/ Author: Milan Georgijevic, Technical SEO Consultant Published: 2026-08-14 An internal link points from one page on a domain to another page on the same domain. Navigation menus, breadcrumbs, category lists, body links and related-content cards are all internal links. Useful internal links help visitors take a logical next step while giving crawlers a route and context about the destination. Google uses links to find new pages and as signals when determining relevance. Every important page should have a link from at least one other discoverable page. Internal linking belongs to both technical SEO, which makes the link crawlable and canonical, and content SEO, which chooses a useful destination and describes it accurately. ### The three jobs of internal links 1. Discovery: a crawlable link gives Googlebot a path to a URL it may not know. 2. Context: the anchor text and surrounding sentence explain the destination and its relationship to the source. 3. Importance: the structure indicates which pages are central and which supply supporting detail. Internal links can help search engines understand a strong page. They do not guarantee rankings and cannot rescue content that fails to answer a useful search intent. ### Crawlable link implementation Use an ordinary HTML anchor with an href that resolves to a real URL and visible text: ```html internal linking guide ``` Text links in rendered HTML, linked images with descriptive alt text, and menu or breadcrumb anchors with real destinations are reliable. Clickable div elements, anchors that only use onclick, destinations hidden behind forms, empty anchors and avoidable redirect chains are fragile. Relative and absolute URLs can both work. Link to the preferred HTTPS URL and keep the host, path case and trailing-slash format consistent with the canonical declaration. ### Logical site architecture Good architecture gives important pages a sensible parent and a short, understandable path from a strong entry point. Common patterns include Home to Service Category to Service, Home to Topic Hub to Detailed Guide, and Home to Category to Subcategory to Product. - Use hubs for real topics and help readers choose among related pages. - Keep primary commercial and informational pages appropriately close to strong entry points. - Link laterally when related pages help each other's readers. - Keep main navigation usable instead of adding every URL. - Avoid giving duplicate, filtered or low-value utility pages more prominence than canonical pages. Click depth is a diagnostic rather than a universal scoring formula. The useful question is whether the page is appropriately easy to reach for its importance and whether the route makes sense to visitors. ### Anchor text Good anchor text is descriptive, concise and relevant to the current page and destination. Clear examples include "how Google Search works," "canonical URL implementation guide" and "reasons a page is not indexed." Generic anchors such as "click here" and "this article" provide less context. Do not force one exact-match anchor everywhere. Natural variations can explain different reasons to visit the same destination. If a sentence sounds unnatural when read aloud, rewrite it. ### Link placement - Primary navigation exposes the sections and commercial pages most visitors need. - Breadcrumbs show hierarchy and provide a route upward. - Hub and category pages distribute visitors into a coherent set. - Contextual body links connect a sentence to a specific useful destination. - Related cards offer optional next steps after the main task. - Footer links provide stable access to selected sections and utilities. When publishing a page, add it to the relevant hub and link from related discoverable pages where it completes an explanation. A sitemap entry supports discovery but does not replace these relationships. ### Orphan pages An orphan page has no crawlable internal link pointing to it. It may appear in a sitemap, CMS, analytics or Search Console while remaining outside normal site navigation. To identify candidates, compare a crawl with sitemap URLs, CMS or database exports, analytics landing pages and Search Console pages. A known indexable URL missing from the crawl may be orphaned or hidden behind an inaccessible route. Not every orphan deserves a link. Obsolete campaigns, duplicates and private utilities may need removal, redirects or noindex. Decide whether the page should exist first. Link important pages from their most relevant hubs and contextual sources. ### Internal-link audit 1. Define the preferred set of indexable canonical URLs. 2. Crawl rendered links and export sources, destinations, anchors, status codes and canonicals. 3. Replace broken destinations and redirect chains with final healthy URLs. 4. Review pages with zero or few inlinks. 5. Check whether important pages sit behind unnecessary click depth. 6. Review vague, repetitive or misleading anchor text. 7. Separate global template links from contextual editorial links. 8. Compare internal destinations with canonical and sitemap URLs. 9. Prioritize pages by business purpose and proven value. 10. Recrawl, verify the new paths and monitor search behavior without promising instant ranking changes. ### Common mistakes Publishing orphan pages, linking to redirects, mixing internal URLs with canonical declarations, using JavaScript buttons without anchors, repeating forced exact-match anchors, adding links by quota, dumping every URL into the footer, applying nofollow internally by default, heavily linking to non-canonical filter pages, and auditing counts without considering page intent. ### Publishing checklist Distinct page intent and one canonical URL. At least one hub or discoverable source link. A contextual link that explains the next step. Real anchor href destinations. Natural descriptive text. Direct links to healthy canonical URLs. Useful outbound internal resources. Intended paths available on mobile and in rendered HTML. Sitemap inclusion when appropriate. ### FAQ **What is an internal link in SEO?** A link from one page on a domain to another page on that domain. It supports navigation, discovery, context and relative importance. **How many internal links should a page have?** There is no universal ideal. Add the links that genuinely help a reader understand or continue. **Does anchor text affect SEO?** It gives people and search engines context. Keep it concise, descriptive and natural. **What is an orphan page?** A page with no crawlable internal link pointing to it. **Should internal links use nofollow?** Ordinary navigation and editorial links within your site normally should not. **Are internal links more important than an XML sitemap?** They serve different jobs. Important pages normally benefit from both useful internal links and sitemap inclusion. --- ## Guide: SEO Meta Tags: The Free On-Page SEO Guide URL: https://ivig.dev/on-page-seo-guide/ Author: Milan Georgijevic Published: 2026-07-14 Updated: 2026-09-19 SEO meta tags describe a page or give indexing and preview instructions. On-page SEO also includes the visible heading, content and internal links. Your title and description influence how a result may appear; Google can choose different text. A canonical suggests a preferred URL, while robots rules control indexing and preview permissions, not whether a crawler can fetch the page. Start with the errors that change what readers or search engines receive: a title copied across several services, an inaccurate description, or a leftover noindex rule on a public page. Check the published page, not only the fields in your editor. Below you'll find what each tag does, what the data says Google actually does with it, copy-paste code for all of them, and a [free snippet preview tool](https://ivig.dev/on-page-seo-guide/#snippet-preview-tool) to test your own titles and descriptions before you publish. ### What Are SEO Meta Tags? Meta tags are instructions for machines. Your visitors never see them. Search engine crawlers, browsers, and social platforms read them on every request and use them to decide three things: what your page is about, how to display it, and whether to index it. They all live inside the `` element, before any visible content. A minimal, healthy head section looks like this: HTML ~~~ Your Page Title ~~~ The title is a `` element and the canonical is a `<link>` element. Neither is technically a meta tag. The H1 is a visible heading in the body. They belong in the same on-page review, but they do different jobs. | Element | Job | Practical check | | --- | --- | --- | | Title | Names this specific page | Does it describe the answer or service rather than repeat a keyword list? | | Meta description | Offers a possible search snippet | Does the summary match what the visitor will actually find? | | H1 | Introduces the visible content | Can someone identify the purpose without reading the menu? | | Robots | Sets indexing and preview rules | Is noindex intentional, and can crawlers access the rule? | | Canonical | Suggests the preferred duplicate URL | Does it point to the correct final page? | | Open Graph | Supplies sharing metadata | Do the title and image fit this page rather than the homepage? | ### Do Meta Tags Still Matter for SEO? Yes, but not equally, and not the way most people assume. Three of them influence rankings directly or through indexing (title, robots, canonical). One influences clicks rather than position (description). The rest handle rendering and sharing. Knowing which bucket a tag belongs to tells you how much effort it deserves. There's a second reason to care that gets far less attention: Google can generate different title links and snippets. The numbers are bigger than most site owners expect. 61.6% of title tags get rewritten by Google in search results Zyppy, study of 80,959 titles 62.8% of meta descriptions get rewritten before they reach the results page Ahrefs, study of 20,000 keywords 25% of top-ranking pages don't have a meta description at all Ahrefs, same study These are historical study samples, not current rewrite rates for your website. A rewritten result does not prove your tag is poor: Google can adapt text to the query and page content. Use the studies as context, then check your own results. ### Title Tag: Describe the Page Clearly Ranking factor A specific title helps readers identify the page. Google can also use headings and other text when generating a title link. Its [title-link guidance](https://developers.google.com/search/docs/appearance/title-link) recommends descriptive, concise titles without repetitive boilerplate or keyword stuffing. HTML ~~~ <title>SEO Meta Tags: Free On-Page SEO Guide (2026) ~~~ #### How long should a title tag be? About 50 to 60 characters can be a useful drafting target, not a Google limit. Display width and wording matter. Keep the subject clear rather than removing a useful word just to satisfy a counter. The historical study below describes its sample; it does not establish a universal rule. How often Google rewrites your title, by length Share of titles Google replaced or modified in search results 1 to 5 charstoo short 96.6% 51 to 60 charsrecommended 39 to 42% Sweet spot Over 60 charstruncation zone 76%+ Over 70 charsalways cut 99.9% Data: [Zyppy title rewrite study](https://zyppy.com/seo/google-title-rewrite-study/), 80,959 URLs from 2,370 websites. Bars in green mark the length with the lowest rewrite rate. 0 characters70+ Under 40: often rewritten 40 to 60 60+ #### Title tag best practices - One unique title per page. Different pages need distinctive labels so readers and search engines can tell them apart. - Put the main keyword near the front. Searchers scan the first words, and truncation eats the end, never the beginning. Choose it through a [keyword research process](https://ivig.dev/keyword-research-guide/) that starts with the audience and task, not volume alone. - Match the search intent. If page one is full of guides, a product page may not satisfy the same learning task. Use this [search intent guide](https://ivig.dev/search-intent-guide/) to identify the task and choose the right page type before polishing the tag. - Prefer dashes over pipes as separators. Zyppy found Google strips pipes from 41% of titles but dashes from only 19.7%. - Keep your title and H1 aligned. When both contained the same number, Google preserved it in 97.3% of displayed titles. - Write for the click, not the crawler. A title that reads like a keyword list gets rewritten. A title that promises something specific gets clicked. ✕ WeakHome | Best SEO | SEO Services | Cheap SEO | SEO Company ✓ StrongTechnical SEO Audit: 42 Checks in Plain English (Free) ### Meta Description: Your Free Ad Copy in Search Results Affects clicks Google has been clear for years: the meta description is not a ranking factor. So why write one? Because it's the only ad copy you'll ever get for free. Two lines of text under your title, shown to people who are actively searching for what you do. A description that answers the searcher's question earns the click that the ten blue links are fighting over. HTML ~~~ ~~~ Now the honest caveat. [Ahrefs compared hardcoded descriptions against live desktop snippets](https://ahrefs.com/blog/meta-description-study/) across 20,000 keywords and found Google rewrites them 62.8% of the time. For long-tail queries it climbs to 65.6%. Google builds its own snippet from your page text whenever it thinks that serves the query better. Write a useful description for each important page, but do not assume it will always appear. Google primarily builds snippets from visible content and sometimes uses the description. Its [snippet guidance](https://developers.google.com/search/docs/appearance/snippet) explains why different searches can produce different summaries. #### Meta description best practices - Lead with the useful detail. A 140 to 160 character draft is a convenience, not a fixed display limit. Snippets vary with the query, device and available space. - Include the keyword once. Google bolds query words in snippets, and bold text pulls the eye. - State what the page delivers, specifically. "Learn more about our services" tells the searcher nothing. Numbers, outcomes and specifics win clicks. - Use active voice and address the reader. It's ad copy. Write it like ad copy. - Never duplicate descriptions across pages. Write a page-specific summary. Google can still select a snippet from visible content, even when the description is duplicated. 0 characters180 Under 110: thin 110 to 160 Cut ### Meta Robots: Control Indexing and Search Previews Controls indexing The robots meta tag is the most dangerous tag on this page. Used well, it keeps thin and duplicate content out of the index so your strong pages get the attention. Used badly, it removes your site from Google and nobody notices for months. A public page carrying a leftover staging `noindex` can disappear from search after Google processes that rule. That is different from a robots.txt block, which prevents crawling. Check both before assuming a content rewrite will fix an indexing problem. HTML ~~~ ~~~ #### The directives that matter Google documents [the full list of robots directives](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag) it supports. These are the ones you'll actually use: | Directive | What it does | Typical use | | --- | --- | --- | | `index` | Allows the page in search results. This is the default, so you never need to declare it. | Nothing. Omit it. | | `noindex` | Removes the page from search results. | Thank-you pages, internal search results, thin archives | | `nofollow` | Stops Google from following any link on the page. | Pages full of untrusted or paid links | | `noarchive` | Ignored by Google Search; its cached-link feature has been removed. | Do not add it for Google cache control | | `nosnippet` | Prevents text snippets and video previews; a static image may still appear. Also restricts direct use in Google AI Overviews and AI Mode. | Content you don't want quoted | | `max-snippet:[n]` | Caps the snippet at n characters. | Publishers limiting reuse | | `max-image-preview:[size]` | Sets image preview size: none, standard or large. | Use large if you want Discover traffic | | `unavailable_after:[date]` | Drops the page from results after a date. | Expiring offers, event pages | | `notranslate` | Stops Google from offering a translated version. | Pages where translation breaks meaning | #### Three robots mistakes I keep finding in audits - Blocking a noindexed page in robots.txt. If crawlers can't fetch the page, they never see the noindex, and the URL can linger in results anyway. Let Google crawl it so it can read the instruction. - Shipping staging tags to production. Developers noindex the staging site (correctly), then deploy the template with the tag still in it. Check your head section after every redesign. - Forgetting non-HTML files. A meta tag can't go inside a PDF. Use the `X-Robots-Tag` HTTP header for PDFs, images and feeds. Most guides skip this entirely, then wonder why gated PDFs rank. ### Canonical Tag: Identify the Preferred Duplicate URL Consolidates signals A page can have duplicate addresses, such as a clean URL and a tracking-parameter version. A canonical suggests which equivalent page should represent the group. Google may already recognize duplicates; it is not accurate to assume every alternate URL automatically splits your rankings. HTML ~~~ ~~~ - Every indexable page should carry a self-referencing canonical. It makes your preferred address explicit, including when tracking parameters create alternate URLs. - Always use the absolute URL, including protocol and domain. Relative canonicals are a classic source of quiet disasters. - It's a hint, not a command. Google can ignore a canonical that contradicts stronger signals like redirects and internal links. If the variants also need consolidating at the server level, use a 301. - One canonical per page. Conflicting canonical targets can be ignored. Keep one consistent declaration rather than relying on competing plugin output. For the decision about retiring or retaining a page, read [canonical tags vs. 301 redirects](https://ivig.dev/canonical-vs-301-redirect/). For duplicate products, parameter URLs, pagination, PDFs and cases where Google selects a different URL, see the full [canonical URL implementation guide](https://ivig.dev/canonical-url-guide/). ### Viewport and Charset: Two Tags You Set Once Rendering These two take thirty seconds and you never touch them again. The viewport tag tells browsers how to scale your page on phones. Google has treated mobile-friendliness as a ranking consideration since 2015, and a missing viewport tag is the fastest way to fail it. The charset declaration sets character encoding so text renders correctly. Use UTF-8, which is what Google recommends. HTML ~~~ ~~~ ### Open Graph and Twitter Cards: Own Your Share Preview Social sharing Open Graph tags decide what appears when your link lands in Facebook, LinkedIn, Slack, WhatsApp, iMessage or Discord. Without them, platforms guess, and the guess is usually a random image with a truncated sentence. Since a shared link is often someone's first contact with your site, the preview deserves the same care as the title tag. HTML ~~~ ~~~ - Make the og:image 1200 by 630 pixels. That's the standard large-preview size across platforms, and smaller images get demoted to a thumbnail layout. - Use absolute URLs for og:url and og:image. Relative paths break previews on several platforms. - X falls back to Open Graph when its own tags are missing, so the one twitter:card line above is usually all you need from that family. - Test before you share. LinkedIn's Post Inspector and Meta's Sharing Debugger show you the exact preview and let you refresh a stale cache. ### Test Your Meta Tags: Live SERP Snippet Preview Type your title and description below and watch the Google-style preview update. The counters track characters and approximate pixel width, which is what Google actually truncates on. No signup, nothing gets sent anywhere, it all runs in your browser. Interactive tool: https://ivig.dev/on-page-seo-guide/ ### A Worked On-Page SEO Example Imagine a fictional bicycle workshop page that explains puncture repairs, prices and booking. "Home | Bikes | Best Bikes" gives a visitor little reason to choose it. A clearer page might use: HTML: fictional workshop page ~~~ Bicycle Puncture Repairs in Bristol | Example Workshop

Bicycle puncture repairs in Bristol

~~~ The title identifies the service and place. The description previews information the page must actually contain. The H1 names the visible subject. Do not copy the city, service or business name unless they describe your page. #### How to check your published tags - Publish one representative page and open its source. Search for the title, description, robots and canonical elements. - Inspect the rendered DOM too if scripts can change the head. Look for duplicate or conflicting output from templates and plugins. - Compare the H1, title and actual answer. They can use different wording without describing different subjects. - Use [Search Console](https://ivig.dev/google-search-console-performance-guide/) to review relevant queries and equal date ranges after recrawling. A changed snippet or a handful of impressions is not proof of a ranking gain. The preview tool above is an approximation for writing, not a screenshot of what Google promises to show. ### Meta Tags You Can Safely Delete Half the meta tags floating around CMS templates do nothing. Some have done nothing for fifteen years. Here's the honest split, based on [Google's own list of supported tags](https://developers.google.com/search/docs/crawling-indexing/special-tags). #### Worth your time - `` on every page, concise and distinctive - `description` on pages that earn search traffic - `robots` where indexing needs control - `canonical` self-reference on every indexable page - `viewport` and `charset`, set once - Open Graph plus `twitter:card` #### Delete on sight - `keywords`: ignored by Google since 2009, a spam signal for Bing since 2011 - `revisit-after`: never supported by any major engine - `http-equiv="refresh"` redirects: use a server-side 301 instead - `generator`: advertises your CMS version to attackers, helps nobody - `nositelinkssearchbox`: the feature it controlled no longer exists ### Meta Tags and AI Search Search traffic increasingly arrives through AI answers: Google's AI Overviews, ChatGPT, Perplexity and friends. Your meta tags are part of how these systems read your site, and the controls overlap almost entirely with classic SEO. - Snippet controls apply to AI features. Google [documents](https://developers.google.com/search/docs/appearance/ai-features) that `nosnippet`, `data-nosnippet`, `max-snippet` and `noindex` limit how your content appears in its AI experiences, the same way they limit classic snippets. Blocking snippets now also means opting out of AI answer visibility, so use them deliberately. - Clear titles help citation. AI assistants show your title and description when they cite a source. A vague title makes an unclickable citation. - Training opt-outs live in robots.txt, not meta tags. The `Google-Extended` token controls whether your content trains Gemini models, and it has no effect on your Search rankings. Different lever, different file. My position, since an expert should have one: don't block AI systems from content you want customers to find. The sites winning AI citations are the ones with clear, well-structured, honestly labeled pages, which is exactly what classic on-page SEO builds anyway. ### Copy-Paste Meta Tag Template Here's the full head section I start every project with. Replace the placeholder text, delete the comments, done. HTML ~~~ <!-- Essentials --> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Primary Keyword: Specific Benefit (Brand) ~~~ ### On-Page Meta Tag Checklist Run this against any page in ten minutes. If all ten pass, your head section is in better shape than most of the web. #### The 10-point check - Unique, descriptive title with the useful subject near the front - Title matches what page one already rewards for the query - Accurate, page-specific description with the useful detail first - Self-referencing canonical with the absolute URL - No unintended `noindex` anywhere (check after every deploy) - `viewport` and `charset` present in the first lines of the head - Open Graph set, share image at 1200 by 630 pixels - `meta keywords` and other dead tags removed - Title and H1 telling the same story - Verified in View Source on the live page, not in the CMS editor ### Want Me to Check Your Site's Head Section? Request a free review of a small selection of public pages. I will email up to five priority findings or next steps. A comprehensive audit or implementation project can be scoped separately. [Request a free review](https://ivig.dev/#free-audit) ### SEO Meta Tags: FAQ **How many characters should a title tag be?** About 50 to 60 characters is a drafting guideline, not a fixed Google limit. Write a concise, descriptive title and check whether its most useful words remain clear when the display is shortened. **How long should a meta description be?** There is no fixed Google character limit. A 140 to 160 character draft can help you stay concise, but the displayed snippet depends on the query and device. Put the useful summary first. **Do meta keywords still matter for Google SEO?** No. Google does not use the meta keywords tag for web search ranking. Focus on useful content, descriptive titles and correct indexing settings instead. **Do meta descriptions affect rankings?** Meta descriptions are not a direct Google ranking factor. A useful description can help someone decide to visit when it is displayed, but rewriting it does not guarantee better rankings or clicks. **What is the difference between a title tag and an H1?** The title element is in the HTML head and labels the browser tab; Google may use it for the search title link. The H1 is a visible page heading. Keep both aligned with the actual subject. **How do I check my meta tags?** Check the published HTML source and, when JavaScript modifies the page, the rendered DOM. Look for duplicate declarations and compare the output with your CMS fields. Use Search Console URL Inspection for indexing information. --- ## Guide: Google Search Console Setup: The Complete Walkthrough URL: https://ivig.dev/google-search-console-setup/ Author: Milan Georgijevic, Technical SEO Consultant Published: 2026-07-14 Google Search Console is Google's free tool that shows how a site performs in search: which queries bring impressions and clicks, which pages are indexed, and what's broken. Setup takes about fifteen minutes: create a property, verify ownership, submit a sitemap. Key facts: completely free (no paid tier); keeps 16 months of performance history on a rolling basis; the only place Google reports first-hand how it sees your site. ### What Search Console does Four questions no other free tool answers: - Which queries show my pages, and where (impressions, clicks, average position for real searches) - Which pages are indexed, with the exact reason for every page that isn't - Is something broken (manual penalties, security issues, Core Web Vitals failures, structured data errors) - Can Google reach my content (live URL testing from Google's crawler) Setting it up does not improve rankings by itself; the value is the feedback loop. ### Domain vs URL-prefix property | | Domain property | URL-prefix property | |---|---|---| | Covers | Everything on the domain: all subdomains, http and https, www and non-www | Only URLs starting with the exact prefix | | Verification | DNS record only | HTML file, meta tag, Analytics, Tag Manager or DNS | | Best for | Almost everyone who can edit DNS | No DNS access, or isolating one section | | Data view | One combined view | Separate property per variant | Recommendation: create the Domain property if you can touch DNS; it catches subdomain and redirect problems a URL-prefix property misses. Add URL-prefix properties on top for isolated views. Running both is fine. ### Verification methods Per Google's official verification documentation: 1. **DNS TXT record** (only option for Domain properties): add a TXT record at the registrar with host @ and value `google-site-verification=your-unique-token`. Sometimes verifies in minutes; propagation can take up to two or three days. The record must stay in DNS permanently because Google rechecks it periodically. 2. **HTML file upload**: upload Google's file to the site root, publicly accessible, no login, no redirect, unmodified. 3. **HTML meta tag**: one line in the homepage head, within the first 2MB. Watch for plugins injecting it into the body and rebuilds dropping it. 4. **Google Analytics or Tag Manager**: piggybacks on an existing snippet. Requires edit rights (GA) or publish rights (GTM) and the same Google account for both products. Pro move: verify with two methods; Google supports multiple tokens, and the second keeps access alive when a redesign drops the first. ### When verification fails: real causes 1. DNS hasn't propagated yet (check with `nslookup -type=TXT example.com`, then wait) 2. The token got "cleaned up" (DNS tidying, redesigns dropping tags, deleted files); verification lapses after a grace period 3. Redirects eat the verification file (the exact URL must return the file, not a redirect to another domain) 4. The tag is outside the head section (plugins often inject it into the body) 5. Wrong Google account for Analytics/Tag Manager verification 6. The homepage requires login or blocks crawlers (staging protection, geo-blocking, aggressive bot filters) ### Submit your sitemap Indexing → Sitemaps → enter the sitemap URL → Submit. Also reference it in robots.txt (`Sitemap: https://example.com/sitemap.xml`). A "Couldn't fetch" status right after submission is usually queue lag; refresh in a few hours. ### First week: 7 things to do after setup 1. Inspect your most important URLs (want: "URL is on Google") 2. Request indexing for new or updated pages 3. Read the Page indexing report once as a baseline; look for important pages in the wrong column 4. Check Manual actions and Security issues (ten seconds, and if not empty it outranks everything) 5. Add a second owner or backup verification 6. Audit titles, descriptions and robots tags alongside the new data (see https://ivig.dev/on-page-seo-guide/) 7. Calendar a monthly 15-minute review: Performance compared to the previous 28 days, plus new Page indexing reasons ### The reports that matter - **Performance**: clicks, impressions, CTR, position per query and page. Average position is the average of your topmost position each time you appeared; a new page ranking #80 for a big query drags the site-wide average down while nothing got worse. Judge query-page pairs, not the site-wide number. - **Page indexing**: every known URL, indexed or not, with reasons. "Crawled, currently not indexed" is usually a content quality signal, not technical. - **URL Inspection**: the indexed version of any URL, Google's chosen canonical, and a live crawler test. Start here when a page should rank and doesn't. - **Core Web Vitals / Enhancements**: real-user performance data and structured data validation; both need traffic before they populate. - **Links**: the only backlink list that comes from Google itself. ### What Search Console won't tell you Documented in Google Search Central's write-up on performance data filtering and limits: - History caps at 16 months, rolling; older data is deleted forever (export via BigQuery or the API if you want multi-year history) - Anonymized queries (made by only a few dozen users over a two to three month window) never show in query tables but are counted in chart totals, which is why rows never add up to the total - The UI exports 1,000 rows; the Search Analytics API and Looker Studio connector go up to 50,000 rows per day per site - Site-wide averages blend hundreds of query-page pairs; always segment before concluding anything ### Interactive method picker The guide includes an interactive verification-method picker at https://ivig.dev/google-search-console-setup/#method-picker: answer two or three questions about DNS and file access, get a recommendation with the gotcha for each method. ### 10-point setup checklist 1. Domain property created (or URL-prefix if DNS is off limits) 2. Ownership verified, token documented 3. Second verification method or second owner added 4. Sitemap submitted and showing "Success" 5. Sitemap also referenced in robots.txt 6. Top pages checked in URL Inspection: "URL is on Google" 7. Manual actions and Security issues both empty 8. Page indexing baseline reviewed 9. Meta tags on key pages reviewed alongside the new data 10. Monthly 15-minute review scheduled ### FAQ **How long does verification take?** HTML file, meta tag, Analytics and Tag Manager: usually instant. DNS: often minutes, up to two or three days per Google. **Is Google Search Console free?** Completely. Every report, every tool, unlimited properties. **Domain or URL-prefix property?** Domain if you can edit DNS; URL-prefix when you can't or want isolated data. Both at once is fine. **Does Search Console improve rankings?** Not by itself; the value is making indexing problems, near-miss queries and errors visible so you can fix them. **Search Console vs Google Analytics?** Search Console covers everything before the click (queries, impressions, positions, indexing); Analytics everything after (sessions, behavior, conversions). **Why does my new property show no data?** Collection starts when the property is added, reports take a few days to populate, and there's no history from before the property existed. Set it up on day one. For a worked example and a repeatable review, read [how to interpret Search Console clicks, impressions, CTR and position](https://ivig.dev/google-search-console-performance-guide/). --- ## Guide: Why Is My Page Not Indexed in Google? How to Find and Fix It URL: https://ivig.dev/page-not-indexed/ Author: Milan Georgijevic. Published July 14, 2026. If URL Inspection already confirms indexing, switch to the [indexed-but-not-ranking checklist](https://ivig.dev/indexed-but-not-ranking/) to investigate search intent, queries and the page itself. A page isn't indexed in Google for one of three reasons: Google hasn't found it, Google found it but hasn't crawled it yet, or Google crawled it and decided not to index it. The URL Inspection tool in Google Search Console tells you which of the three you're dealing with, and the exact status it reports points at the fix. Key numbers: Search Console distinguishes 15 "not indexed" reasons (Google Search Console docs). Google's own guidance says a new page or site can take a week or so to start getting crawled and indexed (Google Search Central). 96.55% of pages get zero traffic from Google, so indexing is the entry ticket, not the prize (Ahrefs search traffic study, 2023, ~14 billion pages). ### How pages get into Google's index Three-stage pipeline; every "not indexed" status names where the page stalled: 1. Discovered — Google learns the URL exists, through a link from a known page or your sitemap. Stalls here: no links, no sitemap entry, or a queue on new sites. 2. Crawled — Googlebot fetches the page, renders it and reads the content. Stalls here: robots.txt blocks, server errors, login walls. 3. Indexed — the page is stored and eligible to appear in results. Stalls here: noindex, duplicates, or a quality verdict. Google's documentation says plainly: "Don't expect every URL on your site to be indexed." The goal isn't 100% coverage; it's every page you care about, indexed, and nothing else. ### Check if a page is indexed, the right way A site:example.com/my-page search is a thirty-second smoke test, not evidence; the site: operator isn't built to show the complete index. The ground truth is the URL Inspection tool in Search Console: whether the URL is on Google, last crawl date, which canonical Google selected, and the specific reason for non-indexed pages. URL Inspection diagnoses single pages; the Page indexing report finds patterns across the site. No Search Console yet? Setup walkthrough: https://ivig.dev/google-search-console-setup/ ### All 15 "not indexed" statuses (from Google's Page indexing report reference) - Discovered - currently not indexed: known URL, not crawled yet. Patience plus internal links. - Crawled - currently not indexed: crawled and declined. A content and duplication question. - Excluded by 'noindex' tag: remove the directive if unintentional (meta robots or X-Robots-Tag header). - Blocked by robots.txt: remove the Disallow rule for pages that should rank. - Soft 404: returns 200 but looks like an error/empty page. Add real content or return an honest 404. - Not found (404): restore or redirect, fine if intentional. - Server error (5xx): fix hosting/application errors, retest. - Redirect error: loop, overlong chain or broken target. Make every redirect a single hop. - Page with redirect: normal plumbing, no action. - Blocked due to unauthorized request (401): remove the login wall or accept exclusion. - Blocked due to access forbidden (403): allow Googlebot through WAF/CDN/hosting rules. - Blocked due to other 4xx issue: fetch the URL yourself, fix the status you see. - Alternate page with proper canonical tag: working as intended, no action. - Duplicate without user-selected canonical: add canonical tags or consolidate. - Duplicate, Google chose different canonical than user: differentiate the pages or strengthen signals toward your choice. The article includes an interactive 30-second troubleshooter that routes you from your URL Inspection verdict to the right section: https://ivig.dev/page-not-indexed/#diagnose ### "Discovered - currently not indexed": stuck in the queue Google knows the URL and hasn't fetched it. Nothing evaluated or rejected your content. Causes: the site is new (unproven domains earn their crawl slowly), weak internal linking, a server that pushed back (slow responses make Google postpone crawls), or thousands of low-value URLs competing for attention. The crawl budget myth: Google's crawl budget guide is written for sites with 1,000,000+ unique pages, or 10,000+ pages changing daily, and tells everyone else "you don't need to read this guide". A 40-page site doesn't have a budget problem, it has a priority problem. What speeds it up: internal links from your strongest indexed pages, a clean submitted sitemap, request indexing for the few URLs that matter, a fast stable server, and links or mentions from sites Google already crawls often. ### "Crawled - currently not indexed": the quality verdict Google fetched, rendered and read the page, then declined to index it. A judgment, not a bug. Causes in the order found on audits: near-duplicate content (location-page clones, identical product variants, tag archives), thin pages, intent mismatch, no internal endorsement, and site-level reputation dragging new pages. The playbook: one search intent per page and make the page the obvious best answer with specifics only you can provide; merge near-duplicates into one strong URL and redirect the rest; link from your best content with descriptive anchors; cut or noindex genuinely thin pages; then request indexing once after real changes. Context for why Google is picky (Ahrefs 2023, ~14 billion pages): 96.55% of pages get zero organic Google traffic, 1.94% get 1-10 monthly visits, 1.51% get more than 10. ### The technical blockers - Forgotten noindex: check for meta name="robots" content="noindex" in the head and the X-Robots-Tag HTTP header (curl -sI https://example.com/page | grep -i x-robots-tag). WordPress: Settings > Reading > "Discourage search engines" is this failure with a friendly face. - robots.txt block: test the path against your robots.txt. Nuance: robots.txt controls crawling, not indexing; a blocked URL can still be indexed as a bare link. To keep a page out of Google, use noindex and let Google crawl it. To rank, be neither blocked nor noindexed. - Canonical pointing elsewhere: copied templates spread wrong canonicals; compare declared vs Google-selected canonical in URL Inspection. - Redirects, 404s, soft 404s: keep redirects single-hop; restore accidentally dead pages; give soft-404 pages real content or an honest 404 status. - Login walls and firewalls (401/403): Googlebot browses anonymously; WAF/CDN bot rules that block it cause 403s. If URL Inspection's live test fails while your browser loads the page, suspect the firewall. ### Requesting indexing, the right way The Request Indexing button moves the URL up the crawl queue. Per Google's URL Inspection docs: indexing after a request "typically takes only a day or so, but can take much longer in some cases", there's "a daily limit to how many index requests you can submit", and "submitting a request does not guarantee that the page will appear in the Google index". It's a priority pass, not a quality waiver. Sequence: fix the cause, request once, wait days. For many pages, Google's advice: "If you want many pages indexed, try submitting a sitemap." ### How long indexing takes A new page or site "can take a week or so" to start being crawled and indexed (Google). John Mueller: "several hours to several weeks", most good content within about a week (via Search Engine Journal). Practical thresholds: recheck after one week, investigate after two to four weeks without a status change, and treat over a month stuck after real fixes as a sign something structural deserves an audit. ### What works vs what wastes your time Worth it: internal links from strong indexed pages, consolidating near-duplicates, a clean current sitemap, one indexing request after a real fix, fixing what URL Inspection's live test reports, mentions from frequently crawled sites. Wastes it: daily indexing requests for an unchanged URL, paid "instant indexing"/ping services, changing the publish date without changing content, deleting and resubmitting sitemaps, buying junk backlinks to force a crawl (can hurt), refreshing site: searches hourly. ### Indexing triage checklist 1. Verdict pulled from URL Inspection, not a site: search 2. Exact status name noted from the Page indexing report 3. No noindex in the HTML head or X-Robots-Tag header 4. robots.txt doesn't block the URL's path 5. Declared and Google-selected canonicals both checked 6. URL returns a clean 200: no chains, no login, no soft 404 7. Page linked from at least one strong, indexed page 8. URL in the sitemap, sitemap shows "Success" in GSC 9. Content honestly beats what's already ranking 10. One indexing request after fixes, then a week of patience ### FAQ **How long does it take Google to index a new page?** Several hours to several weeks. Most good content within about a week per John Mueller; brand-new domains sit at the slow end. **Why is my page indexed but not showing when I search?** Indexed means stored and eligible, not visible. If URL Inspection says "URL is on Google", it's a ranking question, not an indexing problem. **Does requesting indexing multiple times speed things up?** No. There's a documented daily limit and no guarantee. One request after a real fix beats thirty for an unchanged page. **Is "Crawled - currently not indexed" an error?** No, a decision. Some URLs there is normal; act when important pages land there and stay. **How do I get Google to index my site faster?** Clean sitemap, internal links from strong pages, fast server, indexing requests for money pages, and links from sites Google already crawls often. **Do paid indexing services work?** Mostly no. They don't bypass quality evaluation, and junk links from them can hurt. A page that deserves indexing gets there free. --- ## Guide: Sitemap.xml: Why It Matters (and How to Get Yours Right) URL: https://ivig.dev/xml-sitemap-guide/ Author: Milan Georgijevic Published: 2026-07-14 Updated: 2026-09-19 Sitemap.xml is a machine-readable file that lists the URLs on your site you want search engines to crawl and index, along with when each one last changed. It speeds up discovery of new and updated pages, feeds the Sitemaps report in Google Search Console, and takes minutes to set up. It doesn't boost rankings and it doesn't guarantee indexing. This guide covers what the file actually does, who needs one, and how to build and maintain a sitemap that search engines take seriously. Sitemaps sit in a strange spot in SEO advice. Half the internet treats them as a magic indexing button, the other half calls them useless because Google finds links anyway. Both takes miss what the file is for, and most published sitemaps carry fields Google openly says it ignores. So let's set the record straight, with Google's documentation as the referee. 50,000 URLs max per sitemap file (or 50 MB uncompressed). Bigger sites split into multiple files. Google Search Central 2 of 4 standard fields Google ignores outright: changefreq and priority. Most generators still write them. Google Search Central ~500 pages or fewer, well linked internally: Google says you may not need a sitemap at all Google sitemap docs ### What Sitemap.xml Actually Is Google's definition, from its [sitemap documentation](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview): "a file where you provide information about the pages, videos, and other files on your site, and the relationships between them." In practice, for most sites, it's a plain XML file at the root of your domain listing your URLs. A complete, valid sitemap can be this small: sitemap.xml ~~~ https://example.com/ 2026-07-14 https://example.com/services/ 2026-07-01 ~~~ That's not a simplified teaching example. The sitemap serving the site you're reading is exactly this shape, five URLs long, and you can [open it right now](https://ivig.dev/sitemap.xml). XML is the standard format, but Google also accepts RSS and Atom feeds, and even a plain text file with one URL per line. ### What a Sitemap Does (and What It Doesn't) Three real jobs: - It accelerates discovery. Google finds URLs by following links, and a sitemap hands over the full list directly. That matters most exactly when link-following works worst: new sites with few external links, big sites where deep pages sit many clicks down, and freshly published pages nothing links to yet. - It carries metadata crawlers can use. An honest lastmod tells Google which pages changed and deserve a recrawl. Extensions can describe images, videos, news articles and language versions of the same page. - It switches on reporting. Once submitted in Search Console, the Sitemaps report shows how many listed URLs are indexed, and you can filter the Page indexing report to just your sitemap URLs. That turns "is Google seeing my content?" from a guess into a number. And the two jobs it never does. It won't push rankings: a sitemap is a crawling aid, not a quality signal. And it won't force indexing. Google's docs say it plainly: "a sitemap helps search engines discover URLs on your site, but it doesn't guarantee that all the items in your sitemap will be crawled and indexed." If your pages are crawled and still not indexed, the sitemap isn't your problem; my [indexing troubleshooting guide](https://ivig.dev/page-not-indexed/) is the tool for that job. ### Do You Actually Need One? Google's own criteria are refreshingly honest. You likely need a sitemap if the site is large, if it's new with few external links pointing at it, or if you publish lots of media or news content. You may not need one if the site has "about 500 pages or fewer" and every important page is reachable through internal links. My take after years of audits: build one anyway. The cost is minutes, most platforms generate it automatically, and the Search Console reporting alone pays for the effort. "Technically optional" and "not worth having" are different things. Answer the questions below for a recommendation matched to your site. Interactive tool: https://ivig.dev/xml-sitemap-guide/ ### The Four Tags, and Which Ones Google Actually Reads Every URL entry supports four standard fields. Here's each one with Google's documented treatment, which is not what most sitemap generators assume: | Tag | What it says | How Google treats it | | --- | --- | --- | | | The page URL. Required | Read and used. Must be the absolute, canonical URL | | | Date of the last significant change | Used, but only "if it's consistently and verifiably accurate" | | | How often the page supposedly changes | Ignored | | | Your opinion of the page's importance, 0.0 to 1.0 | Ignored | Source: [Google's sitemap build documentation](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap), which states "Google ignores priority and changefreq values" in exactly those words. Search Engine Land's [sitemap guide](https://searchengineland.com/guide/xml-sitemaps) notes Bing has expressed distrust of changefreq too. Translation: that generator plugin dutifully stamping priority 0.8 on every page is decorating a file for a reader who skips those lines. A sitemap with just loc and an honest lastmod does everything a fully decorated one does. Setting priority to 1.0 everywhere has never rescued a single ranking. ### What Belongs in a Sitemap (and What Doesn't) Think of your sitemap as a statement to Google: "these are my real pages, index these." Every URL that contradicts that statement teaches Google to trust the file less. The rule from Google's docs: include canonical URLs you want in search results, nothing else. If choosing that preferred URL is the problem, use the [canonical URL guide](https://ivig.dev/canonical-url-guide/) before rebuilding the sitemap. #### Include - Canonical URLs you want ranking in search - Pages returning a clean 200 status - Indexable pages (no noindex, not robots-blocked) - Absolute https URLs, exactly as canonicalized - Honest lastmod dates, updated on real changes #### Leave out - URLs that redirect somewhere else - Deleted pages (404 or 410) - Noindexed pages and robots.txt-blocked paths - Parameter, filter and session-ID duplicates - Staging, dev and test URLs Why the strictness matters: URL Inspection and the Page indexing report treat sitemap membership as your declaration of intent. Put a noindexed URL in the sitemap and you've told Google "index this" and "don't index this" about the same page. Google resolves the contradiction fine, but every mixed signal makes your site's metadata a little less believable, and you'll chase phantom "issues" in [Search Console](https://ivig.dev/google-search-console-setup/) that are really just sitemap clutter. ### How to Make a Sitemap: A Practical Walkthrough First find out whether your site already generates one. Open `/robots.txt` and look for a `Sitemap:` line. Common locations to check include `/sitemap.xml`, `/sitemap_index.xml` and, on WordPress, `/wp-sitemap.xml`. These are examples, not guaranteed locations. Also check your CMS settings and the Sitemaps report in Search Console. #### 1. Choose one maintained source If your CMS or SEO plugin already produces a correct sitemap, use it. Avoid adding a second manually maintained file that lists different URLs. For a static site, generate the file from the published route list during the build, or maintain a small file alongside the pages. The important question is who updates it when a page changes. #### 2. Build the list of preferred pages For a fictional three-page business site, the intended list could be its homepage, service page and contact page. Check each address before adding it. Leave out redirected addresses, private pages, duplicate tracking URLs and pages deliberately excluded from indexing. Use the final preferred URL, not whatever address happened to be copied from the browser. #### 3. Create the XML file Save this fictional example as UTF-8 text named `sitemap.xml`. Replace all example.com addresses. The date is only an illustration: use a page's real significant modification date, or omit lastmod if you cannot maintain it reliably. sitemap.xml: fictional three-page site ~~~ https://example.com/ https://example.com/services/ 2026-09-19 https://example.com/contact/ ~~~ XML needs entity escaping: an ampersand in a URL must be written as `&` in the file. Keep URL encoding and XML escaping distinct. The [sitemap protocol](https://www.sitemaps.org/protocol.html) explains the format, encoding and examples. #### 4. Publish and validate the file - Upload it at the site root, such as `https://example.com/sitemap.xml`. Confirm the response is successful and contains XML, not a login page or an HTML error with a successful status. - Parse the XML with a validator. A browser that displays the file without an error checks syntax, not whether the listed pages belong there. - Open the listed URLs. Check their response status, canonical declaration, indexing settings and actual content. - Check counts against your intended page list. A valid file with only the homepage can still be missing every service page. #### 5. Reference, submit and maintain it Add the real sitemap address to robots.txt and submit it through Search Console's Sitemaps report. Submission helps discovery; it does not guarantee indexing. Google's [build and submit guide](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) covers supported submission methods and size limits. robots.txt: sitemap declaration ~~~ Sitemap: https://example.com/sitemap.xml ~~~ When a page moves, update the sitemap to its final preferred address. If you are unsure whether the old page should remain available, use the [canonical vs. redirect decision guide](https://ivig.dev/canonical-vs-301-redirect/) first. The sitemap should reflect that decision, not make it for you. A single file is limited to 50,000 URLs and 50 MB uncompressed. Split larger files and use a sitemap index. Include only accurate lastmod values for meaningful page changes, not a new date on every build. ### Big Sites: the Sitemap Index Past 50,000 URLs you must split your sitemap. A sitemap index is a sitemap of sitemaps, and it looks like this: sitemap_index.xml ~~~ https://example.com/sitemap-posts.xml 2026-07-14 https://example.com/sitemap-products.xml ~~~ Here's the trick worth knowing even below the limits: split by content type anyway once you have a few hundred URLs per type. Separate sitemaps for posts, products and categories mean Search Console reports indexing per section. When products index at 40% while posts sit at 95%, you've localized a problem that a single merged sitemap would have averaged into invisibility. Specialized extensions exist for [images, videos and news](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview), plus hreflang annotations for language versions. Most sites don't need them; news publishers and international sites do. ### Submitting and Referencing It Google learns about your sitemap three official ways, and you should use the first two: - Search Console. Indexing, then Sitemaps, paste the URL, Submit. This is the one that switches on reporting. Full walkthrough in my [Search Console setup guide](https://ivig.dev/google-search-console-setup/). If the report says "Couldn't fetch" minutes after submission, wait a few hours before troubleshooting: it's usually queue lag, not a real failure. - robots.txt. One line makes the sitemap discoverable by every crawler, including Bing and the AI crawlers, with no accounts needed: robots.txt ~~~ Sitemap: https://example.com/sitemap.xml ~~~ The third route, the Search Console API, matters for platforms managing many sites programmatically. One thing none of these do: re-submitting an unchanged sitemap over and over. Google rechecks submitted sitemaps on its own schedule, and deleting and re-adding the same file achieves nothing. ### Keeping It Trustworthy The whole value of lastmod rests on one sentence in Google's docs: it's used "if it's consistently and verifiably accurate". Google checks your claims against what it finds when it recrawls. Two failure patterns kill that trust: - The eternal now. Dynamic sitemaps that stamp every URL with today's date on every request claim the whole site changed every day. A few crawls later Google can see the pages didn't change, and your lastmod becomes noise. Tie the date to actual content edits. - The frozen file. A hand-made sitemap from the site launch, never touched again: old URLs that now redirect, new pages missing entirely. Worse than no sitemap, because it actively misdescribes the site. The maintenance rule is one line: the sitemap changes when the site changes, automatically if possible. Publish a page, it appears. Delete a page, it disappears. Change content significantly, lastmod moves. That's the entire discipline, and on a good setup it costs zero ongoing effort. ### Mistakes That Cost Real Traffic From audits, in rough order of frequency: - Redirects and dead URLs in the sitemap. Common after migrations: the sitemap still lists old URLs that now 301. Google follows them, wastes fetches, and flags the mismatch in Search Console. - Noindexed URLs in the sitemap. The classic mixed signal, usually a plugin listing pages another plugin noindexed. Pick a lane per URL; my [meta tags guide](https://ivig.dev/on-page-seo-guide/) covers the robots directives side. - lastmod refreshed everywhere, daily. See above. You get one credibility budget for that field. - Non-canonical variants. The sitemap says http or non-www while canonical tags say https and www. Every URL in the sitemap should match its canonical exactly, character for character. - Staging URLs in production. A build pipeline that bakes dev hostnames into the deployed sitemap. Nobody notices, because nobody opens the file. Open the file. - A sitemap nothing references. Generated, uploaded, never submitted in Search Console, never mentioned in robots.txt. It helps no one there. Two minutes fixes it. - Expecting the sitemap to fix indexing. If pages are crawled but not indexed, the discovery layer already worked. The problem lives in content or site quality, and the fix lives in my [indexing guide](https://ivig.dev/page-not-indexed/), not in this file. ### The Sitemap Hygiene Checklist #### Run this on your live sitemap today - The sitemap URL opens in a browser and renders valid XML - Every URL is absolute, https and matches its canonical exactly - No redirects, 404s, noindexed or blocked URLs inside - Every page you want ranking is present - lastmod reflects real content changes, not generation time - changefreq and priority removed, or at least ignored knowingly - File under 50,000 URLs and 50 MB, split with an index if bigger - Submitted in Search Console and showing "Success" - Referenced in robots.txt with a Sitemap: line - Regenerates automatically when content is added or removed ### Want Someone to Check the Whole Crawl Path? The sitemap is one link in the chain: robots.txt, canonicals, redirects, internal links and rendering all decide what Google actually indexes. I check the full chain in my free review, personally, and tell you what I'd fix first. [Request a free review](https://ivig.dev/#free-audit) ### Sitemap.xml: FAQ **Does an XML sitemap improve rankings?** Not directly. It speeds up discovery and gives you the Sitemaps report in Search Console, but Google states it doesn't guarantee crawling or indexing, and it carries no ranking weight. The indirect value is real: faster discovery of new pages and earlier detection of indexing problems. **Do small websites need a sitemap?** Google says sites with about 500 pages or fewer that are well linked internally may not need one. I still add a sitemap to every site I work on: it costs minutes, updates itself on most platforms, and gives you per-URL indexing data in Search Console you can't get any other way. **How often should a sitemap update?** Every time content is published, significantly updated, or deleted. On most platforms this happens automatically. What matters is that lastmod stays honest: Google uses the field only when it's consistently accurate. **Should I set changefreq and priority?** No. Google documents that it ignores both. A sitemap with just loc and an honest lastmod does everything a fully decorated one does, with less to maintain and less to get wrong. **XML sitemap vs HTML sitemap: what's the difference?** An XML sitemap is a machine-readable file for crawlers. An HTML sitemap is a normal page of links for human visitors, which also spreads internal link value. Different jobs, no replacement relationship. Most sites only strictly benefit from the XML one. **Why does Search Console say "Couldn't fetch"?** Right after submission it's usually queue lag, not an error, so give it a few hours. If it persists: open the sitemap URL in an incognito window, confirm it returns 200 with valid XML, and check robots.txt isn't blocking the file itself. --- ## Guide: Robots.txt Explained: What to Block, What Not To, and Why URL: https://ivig.dev/robots-txt-guide/ Author: Milan Georgijevic. Published July 14, 2026. Robots.txt is a plain text file at the root of your site that tells crawlers which URLs they're allowed to fetch. Google defines its job narrowly: managing crawler traffic, "mainly to avoid overloading your site with requests". It controls crawling, not indexing, and nearly every expensive robots.txt mistake comes from confusing those two jobs. Key numbers (sourced): Google reads at most 500 KiB of the file and ignores the rest (Google Search Central). Google caches robots.txt for up to 24 hours, so fixes aren't instant (Google). The protocol went from Martijn Koster's 1994 invention to a formal standard, RFC 9309, in September 2022 (RFC Editor). ### What robots.txt is One file at https://yourdomain.com/robots.txt. A complete, healthy file for a typical small site: "User-agent: *", an empty "Disallow:" (allows everything), and a "Sitemap:" line with the absolute sitemap URL. The file serving ivig.dev is exactly that: https://ivig.dev/robots.txt ### Crawling vs indexing: the distinction that prevents disasters Robots.txt answers one question: may a crawler fetch this URL? Google is blunt: robots.txt "is not a mechanism for keeping a web page out of Google." A blocked page can still be indexed if other sites link to it (indexed as a bare URL, no content). And the trap inside the trap: a noindex tag on a robots-blocked page does nothing, because Google can't crawl the page to see the tag. To keep a page out of results: allow crawling and use noindex, or password-protect it. To reduce pointless crawling: robots.txt. ### How Google reads the file (all documented behaviors) - One file per host, protocol and port; every subdomain needs its own. - Path values are case-sensitive; field names aren't. - Cached up to 24 hours. - 4xx response for robots.txt = treated as if no file exists (crawl everything). Deleting a broken file is a valid emergency fix. - 5xx response = Google initially stops crawling the entire site for 12 hours, then uses a cached copy for up to 30 days. A server error on this one URL can silently pause your whole crawl. - 500 KiB size limit; content beyond it is ignored. ### Syntax Google supports Four fields: User-agent (names the crawler, * matches all, most specific group wins), Disallow (path prefix the crawler may not fetch; empty = allow all), Allow (re-opens a path inside a disallowed one; more specific rule wins), Sitemap (absolute URL). Crawl-delay is NOT supported by Google. Wildcards: * matches any run of characters, $ pins the end of a URL. Rules are prefix matches: "Disallow: /search" also blocks /searchable-page. ### What to block, what to leave alone Sensible to block: internal search result pages, faceted filter/sort URL explosions, cart/checkout/account paths, infinite spaces (calendars, session IDs, print views), staging sites as a backup behind real authentication. Never block: CSS/JS files needed for rendering (Google renders pages like a browser; blocked assets = broken page in Google's eyes), pages you want removed from results (that's noindex), private content (that's authentication), pages carrying a noindex tag Google needs to read, or the whole site "temporarily". ### AI crawlers User agent tokens: GPTBot (OpenAI, GPT training), OAI-SearchBot (OpenAI, ChatGPT search citations), ClaudeBot (Anthropic, Claude training), PerplexityBot (Perplexity search citations), Google-Extended (Gemini training and grounding). Per Google's crawler documentation, Google-Extended "does not impact a site's inclusion in Google Search nor is it used as a ranking signal"; AI Overviews ride normal Google indexing, so blocking Google-Extended won't remove you from them. Compliance is voluntary: reputable companies honor the file, scrapers ignore it. Whether to block is a business decision: for service businesses, AI citations are free distribution; publishers selling content may decide differently. ### Common mistakes (audit frequency order) 1. The staging block that ships: Disallow: / goes live with a redesign (happened to ivig.dev at launch). Make robots.txt a deployment check. 2. Robots.txt as a privacy tool: the file is public; listing /admin advertises what you hide while stopping only polite bots. 3. Blocking a page AND noindexing it: the block prevents Google from reading the noindex. 4. Blocking rendering assets (CSS/JS). 5. Forgetting subdomains have separate files. 6. Overreaching prefixes: Disallow: /page also kills /pages/pricing. 7. A robots.txt that 5xxes, freezing the whole site's crawl. ### Testing 1. curl -sI https://example.com/robots.txt (must be 200, or intentionally 404). 2. Search Console's robots.txt report (Settings > Crawling) shows Google's fetched copy and parse errors. 3. Run important pages through URL Inspection; "Blocked by robots.txt" on a money page is the finding that pays for the exercise. ### Copy-paste templates Safe default: User-agent: * / empty Disallow / Sitemap line. Junk containment: Disallow /search, /cart, /checkout, /*?sort=, /*?filter= plus Sitemap line. AI-training opt-out while staying in search engines: Disallow: / for GPTBot, ClaudeBot and Google-Extended groups, empty Disallow for *, plus Sitemap line. ### Robots.txt checklist 1. File at the root returning 200 (or intentionally 404) 2. No Disallow: / unless you genuinely mean to vanish 3. CSS, JS and images needed for rendering not blocked 4. Nothing sensitive "protected" by a Disallow line 5. No page both robots-blocked and noindexed 6. Every rule tested against real URLs (prefix behavior checked) 7. Sitemap line present with the absolute URL 8. Every subdomain has its own correct file 9. AI crawler policy decided deliberately 10. Search Console robots.txt report shows no parse errors ### FAQ **Does robots.txt remove a page from Google?** No. Blocked URLs can still be indexed from external links. Use noindex (with crawling allowed) or a password. **Do I need a robots.txt at all?** Not strictly; no file means crawl everything, fine for many small sites. You still want one for the Sitemap line and crawl-trap containment. **Do all bots obey it?** No, compliance is voluntary. Major search and AI companies honor it; scrapers don't. Handle hostile bots at the server level. **Does Google support crawl-delay?** No, documented as unsupported. Bing reads it. **Can robots.txt hide private pages?** The opposite: the file is public and lists what you're hiding. Use authentication. **How do I block AI crawlers?** Disallow rules for GPTBot, ClaudeBot, PerplexityBot, Google-Extended. Voluntary compliance; Google Search and AI Overviews unaffected by Google-Extended blocks. --- ## Guide: HTTP Status Codes Explained: What 200, 301, 404, 410 and 5xx Mean for SEO URL: https://ivig.dev/http-status-codes-guide/ Author: Milan Georgijevic Published: 2026-07-15 Updated: 2026-09-19 HTTP status codes are three digit numbers your server sends with every response: 200 means the page is fine, 301 means it moved for good, 404 means it doesn't exist, 5xx means the server itself failed. Google reads these codes on every crawl and acts on them, deciding what gets indexed, what gets dropped, and how hard your site gets crawled at all. Most of the codes never matter for SEO. About eight of them decide a lot, and this guide covers exactly those. The stakes are asymmetric. The right code is invisible; nobody praises your 301. The wrong one quietly removes pages from Google or fills your index with junk, and the traffic graph is usually how you find out. The good news: the whole system is checkable with one terminal command and one Search Console report. 10 Redirect hops Googlebot follows before it gives up on a chain entirely Google Search Central 0 Ranking penalty from 404s. The dead page drops out, the rest of your site is untouched Google Search Central 429 The one client error Google treats as a server problem, slowing crawls instead of dropping the page Google Search Central ### The Five Classes at a Glance The first digit sorts every code into one of five families, and that digit alone tells you most of what Google will do next. The full picture lives in Google's [HTTP status codes documentation](https://developers.google.com/search/docs/crawling-indexing/http-network-errors), which this guide quotes throughout: | Class | It means | What Google does | | --- | --- | --- | | 1xx Informational | Handshake in progress | Nothing you'll ever act on for SEO | | 2xx Success | The request worked | Passes the content onward toward indexing | | 3xx Redirection | The answer lives at another URL | Follows the hop, up to 10 in a chain | | 4xx Client error | The URL is wrong, gone or off-limits | Treats the content as nonexistent, drops it from the index | | 5xx Server error | Your server failed to answer | Slows crawling, and drops pages if the errors persist | Two families do the real work. Everything interesting in SEO happens in the 3xx and 4xx rows, plus one success code that lies. The rest of this guide walks through them in the order you'll meet them on a real site. ### 200: Success, Not a Promise A 200 says the server delivered the page. That's all it says. Google's documentation is precise here: on a 2xx response, Google "considers the content for processing". Considers. A 200 gets you into the pipeline; it doesn't get you indexed. If your pages return 200 and still don't show up in Google, the problem lives further down the pipeline, and my [indexing guide](https://ivig.dev/page-not-indexed/) walks through all fifteen reasons. The 200 rule that actually bites people is the inverse: only real, useful pages should return it. When your error page, empty search result or "product no longer available" notice answers with 200, you've created a soft 404, which gets [its own section below](https://ivig.dev/http-status-codes-guide/#soft-404). And your [sitemap](https://ivig.dev/xml-sitemap-guide/) should contain nothing but 200 URLs; every redirect or dead link in there burns crawler trust. ### Redirects: 301, 302, 307 and 308 A redirect answers "the page you want is over there". The SEO question is whether the move reads as permanent or temporary, because Google's [redirect documentation](https://developers.google.com/search/docs/crawling-indexing/301-redirects) treats the two differently: a permanent redirect is "a signal that the redirect target should be canonical", meaning the new URL inherits the old one's place, while a temporary redirect keeps the old URL in the results and inherits nothing. | Code | Meaning | Google's treatment | | --- | --- | --- | | 301 | Moved permanently | Strong signal: target becomes canonical, signals consolidate there | | 308 | Moved permanently, stricter about request methods | Same as 301 | | 302 | Found, temporarily elsewhere | Weak signal: source URL stays in results | | 303 / 307 | Temporary variants | Treated like 302 | The decision is simpler than the table: permanent move, 301. Genuinely temporary situation (an A/B test, a seasonal swap, a page briefly parked), 302. The classic mistake is shipping a migration on 302s because that's what the platform defaulted to, then wondering why the old URLs still rank while the new ones sit ignored. Three rules keep redirects from leaking value: - One hop. Googlebot follows up to 10 redirect hops, but every hop past the first is waste. Migrations stack: http to https, non-www to www, old slug to new slug, and suddenly one click triggers four redirects. Point everything at the final URL directly. - Like for like. Redirect each old URL to its closest matching replacement. Google's [site move documentation](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) warns against pointing many old URLs at "one irrelevant single URL destination, such as the home page", which "might be treated as a soft 404 error". - Leave them running. Google recommends keeping redirects live "generally at least 1 year", and indefinitely if users still follow old links. Redirects aren't scaffolding you tear down after launch week. This site practices what it preaches: when I retired the old `/seo` landing page, its content was folded into the homepage, so its URLs 301 there, which is the consolidation case Google explicitly allows. The redirects stay live indefinitely because old ad clicks and bookmarks keep arriving. Server-side redirects are also the only kind worth trusting: Google interprets meta refresh and JavaScript redirects when it can, but its own documentation ranks them below a proper server response. .htaccess examples ~~~ # Permanent move, one hop, like for like Redirect 301 /old-guide/ https://example.com/new-guide/ # Deleted for good, no replacement exists Redirect 410 /discontinued-product/ ~~~ ### 404 vs 410: Pages That Are Gone A 404 says "not found". A 410 says "gone, and on purpose". Google's handling of both is identical in the way that matters: URLs returning either code are dropped from the index, and Google's documentation states plainly that already-indexed URLs returning 4xx "are removed from the index". The 404 vs 410 debate has consumed years of forum arguments, so here's Google's John Mueller [settling it in 2024](https://www.searchenginejournal.com/googles-john-mueller-clarifies-404-410-confusion-for-seo/513576/): "The difference in processing of 404 vs 410 is so minimal that I can't think of any time I'd prefer one over the other for SEO purposes." In the same thread: "Google does not penalize for 404's (those pages drop out of the index though)." That echoes Google's own [position since 2011](https://developers.google.com/search/blog/2011/05/do-404s-hurt-my-site): 404 errors don't hurt your site's ranking. So when should you care about a 404? Ask what the URL was worth: - The page had rankings, traffic or backlinks. A 404 here is a real loss; everything the page earned evaporates. If a genuine replacement exists, 301 to it. If not, accept the 410 and move on. - The URL never existed. Typos, scraper guesses, broken external links to pages you never published. A 404 is the correct, healthy answer. Chasing a zero-404 report is chasing a number Google doesn't care about. - The page is gone and has no replacement. Return 404 or 410 and let it drop. Do not redirect it to the homepage; you read what Google calls that in the previous section. Make the 404 page useful anyway. The status code is for Google; the page itself is for the human who followed a dead link. A search box, links to your main sections, and a plain "that page doesn't exist" outperform a witty dead end. Just confirm the page returns an actual 404, because a custom error page serving 200 is the most common soft 404 I find. ### Soft 404s: The Success Code That Lies Google's [definition](https://developers.google.com/search/docs/advanced/crawling/soft-404-errors): a soft 404 is "a URL that returns a page telling the user that the page does not exist and also a 200 (success) status code". The content says dead, the code says alive, and Google believes the content. Search Console flags these as "Soft 404" in the page indexing report, and the affected URLs don't get indexed. Why it matters beyond the flagged URL: per Google's docs, a success code on a nonexistent page means "search engines will continue trying to crawl that non-existent URL instead of spending time crawling your real pages". On a big site, thousands of soft 404s quietly eat the crawl capacity your real pages needed. Where they come from, in the order I find them on audits: - Custom error pages returning 200. The designer built a lovely 404 page; the server serves it with a success code. - JavaScript sites. The server sends a 200 shell for every route and the app renders "not found" client-side. Every dead URL on the site is now a soft 404. - Empty states. Category pages with zero products, search results with zero hits, expired listings that keep their URL. - Homepage redirects. Dead URLs mass-redirected to the homepage, which Google may classify as soft 404s because the destination has nothing to do with the request. The fix follows the content. Gone for good: return a real 404 or 410. Moved or replaced: 301 to the replacement. Thin but legitimate: make the page worth indexing, or noindex it (my [meta tags guide](https://ivig.dev/on-page-seo-guide/) covers the directive). Then verify with URL Inspection, because the report only updates after a recrawl. ### The Quiet Ones: 304, 401, 403 and 429 Four codes you'll meet in crawl logs and Search Console that rarely need action, and one that does: | Code | Name | SEO meaning | | --- | --- | --- | | 304 | Not Modified | Healthy. Your server told Google the page hasn't changed since the last crawl, saving everyone bandwidth | | 401 | Unauthorized | Google treats the content as nonexistent. Correct for genuinely private pages, fatal on public ones | | 403 | Forbidden | Same treatment as 401. Often a firewall or bot protection blocking Googlebot by mistake | | 429 | Too Many Requests | The exception in the 4xx family: Google reads it as "server overloaded" and slows crawling, like a 5xx | The one that does need action is 403, because it's almost never intentional. CDNs and security plugins ship rules that challenge or block datacenter traffic, Googlebot crawls from datacenters, and suddenly your pages are "Blocked due to access forbidden" in Search Console while looking perfectly fine in your browser. If indexed pages start dropping and you never touched them, check what your firewall serves to Googlebot before you check anything else. ### 5xx: When the Server Itself Fails Server errors trigger a different reflex in Google than dead pages do. Per the documentation, 5xx and 429 errors "prompt Google's crawlers to temporarily slow down with crawling", and URLs that keep erroring are eventually dropped from the index. Google backs off to protect your server, which is polite, but it means a flaky server gets crawled less, indexed less, and refreshed less. Two 5xx situations are worth engineering deliberately: - Planned maintenance gets a 503. A 503 Service Unavailable with a `Retry-After` header says "temporary, come back later" in the language crawlers speak. Your rankings ride out a few hours of 503 without drama. A maintenance page returning 200 risks having "We'll be right back" indexed as your content. - Robots.txt must never 5xx. A server error on that one file halts crawling of your entire site for 12 hours, and the details are ugly enough that [my robots.txt guide](https://ivig.dev/robots-txt-guide/) gives them a full section. Maintenance mode with a 503 (.htaccess) ~~~ # Everyone gets a 503 except your own IP RewriteEngine On RewriteCond %{REMOTE_ADDR} !^198\.51\.100\.7$ RewriteRule .* - [R=503,L] ErrorDocument 503 /maintenance.html Header always set Retry-After "3600" ~~~ If 5xx errors show up in Search Console's crawl stats without any deploy or outage you know about, the usual suspects are an overloaded shared server, a PHP error on a specific template, or a rate limiter counting Googlebot as an attacker. The crawl stats report tells you which URLs and when; your server's error log tells you why. ### Which Code Should This URL Return? Describe the situation, get the right status code. Runs entirely in your browser. Interactive tool: https://ivig.dev/http-status-codes-guide/ ### Checking Status Codes in Thirty Seconds You never have to guess what a URL returns: - One URL, from a terminal. `curl -I` shows the status line; add `-L` to follow and print every hop of a redirect chain: Terminal check ~~~ curl -sI https://example.com/some-page/ # first line: HTTP/2 200 curl -sIL https://example.com/old-page/ # prints every hop in the chain curl -sI -A "Googlebot" https://example.com/ # what your firewall serves to bots ~~~ - One URL, as Google sees it. URL Inspection in [Search Console](https://ivig.dev/google-search-console-setup/) shows the status code from Google's last real crawl, plus the indexing verdict that followed. - The whole site. Search Console's page indexing report groups every excluded URL by reason: "Not found (404)", "Soft 404", "Page with redirect", "Blocked due to access forbidden (403)", "Server error (5xx)". A crawler like Screaming Frog (free for 500 URLs) gets you the same data on demand, plus every internal link that points at a non-200 URL. ### The Mistakes I Keep Finding on Audits - The custom 404 page that returns 200. Beautifully designed, correctly worded, wrong status code. Every dead URL on the site becomes an indexable page. - Migration chains. http to https to www to new-slug: four hops before content. Each stacked migration added a layer, and nobody flattened them. Collapse chains to one hop and update internal links to final URLs. - Permanent moves on 302s. Some platforms and load balancers default to temporary redirects. Google keeps the old URL canonical, the new page inherits nothing, and the migration "mysteriously" underperforms. - Everything redirects to the homepage. The lazy migration: 3,000 old URLs, one destination. Google calls this out by name as likely soft 404 treatment, and every one of those URLs loses whatever it had earned. - Firewalls serving Googlebot a 403. Bot protection tuned too aggressively blocks the one bot you wanted. If pages drop from the index while working fine in your browser, test with a Googlebot user agent first. - Maintenance behind a 200. A week of "back soon" served as success, and Google indexes the apology. Use a 503 with Retry-After, and keep it short. - Internal links pointing at dead or redirected URLs. The codes are correct; the links are stale. Every internal link into a 404 wastes the click, and every link into a 301 wastes a hop. Crawl your own site and point links at final URLs. ### The Status Code Checklist #### Run this against your site today - Every page you care about returns 200 (spot-check with curl -I) - Permanent moves use 301 or 308, in a single hop - Redirects point at like-for-like pages, not the homepage - Deleted content returns 404 or 410, and the error page itself returns the real code - No "Soft 404" entries in Search Console's page indexing report - Maintenance windows return 503 with a Retry-After header - Firewall and bot protection serve Googlebot 200s, not 403 challenges - Internal links point at final URLs: no links into 404s or redirect hops - Sitemap contains only 200 URLs - Robots.txt returns 200 or 404, never a 5xx ### Not Sure What Your URLs Are Actually Returning? Status code problems hide well: the site looks fine in a browser while Googlebot sees 403s, chains and soft 404s. I check response codes, redirects, indexing and the full crawl path in my free review, personally, and tell you what I'd fix first. [Request a free review](https://ivig.dev/#free-audit) ### HTTP Status Codes: FAQ **Do 404 errors hurt my SEO?** Not directly. Google has said since 2011 that 404 errors don't hurt a site's ranking, and Mueller repeated in 2024 that Google doesn't penalize them. What hurts is a page you cared about returning 404: its rankings, traffic and backlink value go with it. Fix those; ignore 404s on URLs that never existed. **Should I return 404 or 410 for deleted pages?** Either. Both drop the page from the index, and Mueller called the processing difference "so minimal" he couldn't prefer one for SEO. 410 is the precise choice for deliberate deletion, so use it when it's easy. Don't re-engineer your stack for it. **Do 301 redirects pass ranking signals?** Yes. Google's documentation calls a permanent redirect a strong signal that the target should be canonical, so the new URL inherits the old one's standing. Point it at the closest matching page, keep it to one hop, and leave it live for at least a year. **How many chained redirects will Google follow?** Up to 10 hops, per Google's documentation. That's a ceiling, not a budget: every hop past the first wastes crawl time and slows users. After migrations, collapse chains to a single hop and update internal links to point at final URLs. **What status code should a maintenance page return?** 503 Service Unavailable with a Retry-After header. Crawlers read it as "temporary, come back later" and your indexed pages ride it out. A maintenance page on a 200 risks getting "we'll be right back" indexed in place of your content. **What is a soft 404 and how do I fix it?** A page that says "not found" or sits nearly empty while returning a 200 success code. Google spots the mismatch from the content and excludes the URL. Fix it with a real 404 or 410 for gone content, a 301 to a genuine replacement, or by making the thin page worth indexing. Need to choose between keeping an alternate URL and moving its visitors? Read [Canonical Tag vs. 301 Redirect: Which Should You Use?](https://ivig.dev/canonical-vs-301-redirect/) for worked examples and a verification checklist. --- ## Guide: How to Set Up Google Analytics 4 (and the Five Settings Everyone Misses) URL: https://ivig.dev/ga4-setup-guide/ Author: Milan Georgijevic. Published July 15, 2026. To set up Google Analytics 4: create a property at analytics.google.com, add a web data stream to get a Measurement ID, install the Google tag through your CMS, the gtag.js snippet or Tag Manager, and confirm your visit in the Realtime report. That's the ten minute half. The half that matters long-term: raising data retention from its 2 month default, filtering your own traffic, linking Search Console, and defining key events. Key numbers, all from Google Analytics Help: new properties default to 2 months of event data retention (raise to 14 months, not retroactive); data collection may take up to 30 minutes to begin; reports and explorations can take 24-48 hours to process data. ### Before you start - GA4 is the only Google Analytics. Standard Universal Analytics stopped processing hits on July 1, 2023, and access to UA data, interface and API ended starting July 1, 2024. Anything mentioning "UA-" IDs describes a dead product. - GA4 measures events, not pageviews with extras. Pageviews, scrolls, clicks and form submits are all events. - History starts at install. GA4 can't backfill; every postponed week is data that never existed. ### Step 1: Create the account and property At analytics.google.com: Start measuring (or Admin, Create, Property). Name the account after the business, the property after the site. Set reporting time zone and currency immediately; changing the time zone only affects data going forward. ### Step 2: Add a data stream Choose Web, enter the site URL, name the stream, leave enhanced measurement on. The stream details page shows the Measurement ID (starts with "G-"). It's an address, not a secret. ### Step 3: Install the tag (pick exactly one route) 1. CMS/platform integration: WordPress (Site Kit or SEO plugin field), Shopify, Wix, Squarespace accept the Measurement ID directly. Use this when available. 2. gtag.js snippet: paste into the head of every page (async script from googletagmanager.com/gtag/js?id=G-XXXXXXXXXX plus the dataLayer/gtag config lines). 3. Google Tag Manager: install the GTM container, add a "Google Analytics: GA4 Configuration" tag with the Measurement ID, trigger on All Pages. Worth it for multiple tools and frequent event changes; overkill for a five page site. Two tags at once means doubled pageviews and broken data. ### Step 4: Verify Open the Realtime report, visit your own site, watch yourself appear. Collection may take up to 30 minutes to begin. Standard reports take 24-48 hours; day-one emptiness is normal. ### The five settings to change on day one 1. Raise data retention to 14 months (Admin, Data retention). Default is 2 months; governs explorations and funnels; not retroactive. 2. Filter your own traffic: define internal traffic by IP in the stream's tag settings, then in Data filters switch the internal traffic filter from "Testing" to "Active". It ships in testing mode and does nothing until flipped. 3. Link Search Console (Admin, Product links) to join queries and landing pages to behavior. Requires a verified GSC property (see the GSC setup guide at https://ivig.dev/google-search-console-setup/). 4. Mark key events: decide which events mean business results and toggle them under Admin, Events. 5. Link Google Ads if you run ads, so key events feed bidding. No ads, skip it. ### Enhanced measurement events (automatic, per Google's documentation) - page_view: page loads or browser history state changes (covers SPAs) - scroll: first time a visitor reaches 90% depth - click: outbound link clicks - view_search_results: internal site search results (via URL query parameter) - video_start / _progress / _complete: embedded YouTube engagement - file_download: clicks on links to PDFs, documents, media - form_start / form_submit: first form interaction, form submission Warning: the automatic form_submit fires on browser-level form activity including search boxes and failed validations. Fine for spotting activity, too blunt for counting leads. ### Key events A key event measures "an action that's particularly important to the success of your business" (Google; the setting was formerly called conversions). GA4 counts nothing as important by default. The clean pattern for lead gen: fire your own named event (e.g. generate_lead) in the form's success handler after the server confirms, then mark it as a key event under Admin, Events. This site's audit form does exactly that, which keeps failed submits, double clicks and bot noise out of the lead count. Two or three key events beat ten. ### Consent mode For EU/UK visitors a consent banner is required. Consent mode loads the tag with analytics_storage and ad_storage defaulted to denied and upgrades via gtag('consent', 'update', ...) when the visitor accepts. This site runs that exact pattern. Costs: declines mean undercounting (treat GA4 numbers as a floor), but skipping the banner risks real fines. ### Mistakes found on real audits 1. Retention left at 2 months, discovered during a year-over-year request. 2. Internal traffic filter stuck in "Testing". 3. Two tags on one site (forgotten plugin plus manual snippet). 4. Counting enhanced measurement form_submit as leads. 5. No Search Console link. 6. Expecting UA numbers: GA4 computes sessions, users and engagement differently; old bounce rate is gone. 7. Waiting for the perfect measurement plan while zero data collects. ### Setup checklist Property with correct time zone and currency. Web stream with enhanced measurement on. Tag installed by exactly one method on every page. Visit appears in Realtime. Retention raised to 14 months. Internal traffic defined and filter Active. Search Console linked (Ads too if applicable). A real success event fires on the money action and is marked key. Consent mode wired to the cookie banner. Reports checked after 48 hours, not 4. ### FAQ **Is GA4 free?** Yes, the standard version covers small and mid-size site needs including explorations and BigQuery export. The 360 tier is for enterprise volumes. **Why no data yet?** Collection may take up to 30 minutes to begin; reports take 24-48 hours. Check Realtime first. **Do I need Google Tag Manager?** No. gtag.js or a CMS field collects the same data. GTM pays off with multiple tools or frequent event changes, and layers on later. **Why do explorations only show 2 months?** Default retention. Raise to 14 months; not retroactive. **Does GA4 affect SEO?** The tag doesn't change rankings and Analytics data isn't a ranking signal. Value is indirect: engagement data plus the Search Console join. **Can I still access Universal Analytics data?** No. Processing stopped July 1, 2023 (standard); all access ended starting July 1, 2024. Unexported data is gone. --- ## Guide: Core Web Vitals Explained: How to Read, Diagnose and Fix LCP, INP and CLS URL: https://ivig.dev/core-web-vitals-guide/ Author: Milan Georgijevic Published: 2026-07-15 Updated: 2026-09-19 For a reproducible example, trace-reading steps and a release checklist, use the [guide to finding and fixing slow interactions](https://ivig.dev/improve-inp-guide/). Core Web Vitals are Google's three measurements of real user experience: Largest Contentful Paint (LCP) for loading speed, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when LCP stays within 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, all at the 75th percentile of real visits. They're measured from actual Chrome users, not from your test runs, which is exactly why so many sites think they pass while their visitors know otherwise. I optimize these numbers for a living, and most Core Web Vitals confusion I meet isn't about code. It's about measurement: which number Google actually grades, why the lab score lies, and where the real data lives. So before the fixes, this guide spends real time on reading the instruments. 2.5 s LCP target: the main content should be painted within 2.5 seconds. Poor starts at 4 seconds web.dev 200 ms INP target: from any tap or click to the next visual frame. Poor starts at 500 milliseconds web.dev 0.1 CLS target: how much the layout jumps around, scored, not timed. Poor starts at 0.25 web.dev ### What Core Web Vitals Actually Are Every visit to a page has three moments where the experience can fall apart, and each vital guards one of them: 1 #### It loads The visitor waits for the main content to appear. LCP times this moment. Fails when: heavy images, slow servers, render-blocking code 2 #### It holds still Content settles without jumping as late elements arrive. CLS scores the jumping. Fails when: images without dimensions, injected banners, swapping fonts 3 #### It responds Taps and clicks produce visible feedback fast. INP times every interaction. Fails when: heavy JavaScript, long tasks, bloated third-party scripts The definitions live in Google's [web.dev documentation](https://web.dev/articles/vitals), which this guide quotes throughout. The set changed once: INP [became a stable Core Web Vital on March 12, 2024](https://web.dev/blog/inp-cwv-launch), replacing First Input Delay, so any advice you read about "FID" predates the current rules. ### The Three Metrics and Their Thresholds | Metric | Measures | Good | Poor | | --- | --- | --- | --- | | LCP Largest Contentful Paint | Time until the largest visible element (hero image, headline block) is painted | ≤ 2.5 s | > 4 s | | INP Interaction to Next Paint | Time from an interaction to the next visual frame, across the whole visit | ≤ 200 ms | > 500 ms | | CLS Cumulative Layout Shift | How far visible content jumps around, as impact times distance, summed | ≤ 0.1 | > 0.25 | Three details worth having straight: - LCP has a specific candidate list. Per [the LCP definition](https://web.dev/articles/lcp): images, video posters, CSS background images, and text blocks. In practice it's almost always your hero image or your headline, which is why LCP fixes are so targeted. - INP watches everything. Not just the first click. Per [the INP definition](https://web.dev/articles/inp), it measures "the time from the start of the interaction to the moment the next frame is fully presented", for clicks, taps and keypresses through the page's whole life. One janky menu on an otherwise fast page can own your INP. - CLS is a score, not a time. Each shift is scored as impact fraction times distance fraction (how much of the viewport moved, times how far), then summed per [the CLS definition](https://web.dev/articles/cls). That's why one full-width banner injection hurts more than ten tiny wiggles. ### The 75th Percentile Rule (Why Your Fast Laptop Lies) Google doesn't grade your average visit. Per web.dev, the assessment uses "the 75th percentile of page loads, segmented across mobile and desktop devices". Translated: line up all real visits from slowest to fastest, walk to the 75% mark, and that visit is your score. A quarter of your visitors experiencing something worse than 2.5 seconds means you fail LCP, even if the median visit is quick. This single rule explains the most common conversation in performance work: "it's fast on my machine". Of course it is. You're on a warm cache, fiber, and a desktop CPU. The 75th percentile visitor is on a mid-range Android phone, on mobile data, seeing your site for the first time. That's the person Google measures you by, and the person your fixes have to serve. ### Field vs Lab: The Two Kinds of Data (and the Score That Doesn't Count) Every Core Web Vitals tool draws from one of two wells, and confusing them costs real money: - Field data comes from the Chrome User Experience Report (CrUX): anonymized measurements from real Chrome users, aggregated, per Google's [PageSpeed Insights documentation](https://developers.google.com/speed/docs/insights/v5/about), "over the previous 28-day collection period". This is what Search Console reports and what matters for search. - Lab data comes from Lighthouse simulating one page load on fixed hardware and network conditions. It's a diagnostic instrument: reproducible, detailed, and blind to what real users experience. The trap: the big performance score at the top of PageSpeed Insights is lab-only. Google's own documentation is explicit that "having good lab data does not necessarily mean real-user experiences will also be good", and the reverse holds too. I've audited sites agonizing over a lab score of 82 while their field assessment passed comfortably, and sites celebrating a lab 98 while real users on real phones failed INP daily. Read the field section first, always. The lab score is for finding causes, not for judging outcomes. In a [complete SEO audit](https://ivig.dev/seo-audit-checklist/), performance is one evidence stream beside crawlability, indexing, content and business impact. Low traffic? No data is normal. CrUX only publishes numbers for pages and origins with enough visits to report reliably. A quiet site shows "no data" in the report, which means unmeasured, not failing. Keep the fundamentals clean with lab tools and revisit when traffic grows. ### Do Core Web Vitals Affect Rankings? An Honest Answer Google's [Search Central documentation](https://developers.google.com/search/docs/appearance/core-web-vitals) puts it carefully: good Core Web Vitals align "with what our core ranking systems seek to reward". That's a real signal, and a deliberately modest phrasing. Vitals are not a rocket strapped to your rankings; they're one factor among many, and content relevance outweighs them every day of the week. So here's the honest hierarchy. If your page isn't indexed, vitals are irrelevant (start with my [indexing guide](https://ivig.dev/page-not-indexed/)). If your content doesn't answer the query, vitals won't save it. But between comparable pages competing for the same intent, experience signals break ties, and more importantly: slow pages lose visitors before any ranking question arises. A visitor who bounces at second three of a five second load never sees your content, your form, or your phone number. That cost is immediate and shows up in revenue, whatever the algorithm thinks. ### Fixing LCP: Make the Main Thing Arrive First Find your LCP element first (PageSpeed Insights names it in the diagnostics). It's usually the hero image or headline. Then, in descending order of typical impact: - Stop lazy-loading the hero. `loading="lazy"` on the LCP image is the most common self-inflicted LCP wound I see. Lazy-load below the fold, never the top. - Tell the browser the hero matters. `fetchpriority="high"` on the LCP image moves it up the download queue. The featured image on this very page uses it. - Shrink what you ship. Serve modern formats and honest dimensions. A 2 MB PNG scaled down by CSS is pure waste; this site's hero images are optimized JPEGs under 60 KB. - Fix the server first if TTFB is slow. LCP includes the time before the first byte arrives. Caching, a CDN, or better hosting often beats any front-end trick. - Unblock the render path. Defer non-critical JavaScript, keep critical CSS lean, and load fonts with `font-display: swap` so text doesn't wait on font files. LCP-friendly hero image ~~~ ... ... ~~~ To see which of the four LCP phases is slow before choosing a fix, use the [step-by-step LCP guide](https://ivig.dev/improve-lcp-guide/). ### Fixing INP: Give the Main Thread Room to Breathe #### Find the Slow Interaction Before Choosing a Fix Write down the action that feels slow: opening the mobile menu, filtering products, submitting a form or selecting a tab. Reproduce it after the page has loaded and while normal third-party scripts are running. A page-load test alone does not exercise these actions. - Start with available field data. Check whether the report describes the specific URL or the whole origin. If there is insufficient real-user data, say so; a lab result is not a replacement field pass. - Record the interaction. Use Chrome DevTools' Performance panel to capture the actual click or keypress. Note the page, device conditions and action so someone else can repeat it. - Find where time goes. Separate waiting before handlers run, time spent processing the event and the rendering work before the next visible frame. - Change one cause and retest. Compare the same action under similar conditions, then review field data when enough new visits are available. For example, a filter can update its selected state quickly but spend too long rebuilding the product grid. That calls for investigating the update and rendering work, not compressing an unrelated hero image. Google's [INP optimization guide](https://web.dev/articles/optimize-inp) explains the input-delay, processing and presentation phases. INP suffers when the browser's main thread is too busy running JavaScript to draw the next frame after a tap. The fixes are about doing less, later: - Audit third-party scripts ruthlessly. Chat widgets, heatmaps, tag managers stuffed with forgotten pixels: each one competes with your visitor's tap. Remove what nobody uses; load the rest after the page is interactive. - Break long tasks. Any script chunk running past 50 ms blocks every interaction that arrives during it. Split heavy work and yield to the browser between chunks so input can slip in. - Respond first, compute second. On a click, paint the feedback (open the menu, toggle the state), then do the expensive part afterward. The visitor needs to see something happen within 200 ms; the bookkeeping can wait. - Watch the DOM size. Rendering cost scales with complexity. Thousand-node pages recalculate slowly, and every interaction pays that tax. INP is the vital most likely to need a developer rather than a plugin, because diagnosis may involve JavaScript scheduling, event handlers and rendering work rather than one page-load setting. ### Fixing CLS: Reserve the Space Before It's Needed Layout shift has one root cause: content arriving without space reserved for it. The fixes are mechanical and satisfying: - Dimensions on every image and video. `width` and `height` attributes let the browser reserve the box before the file arrives. Every image on this site carries them. - Reserve slots for ads, embeds and banners. Give the container a fixed size or `min-height` in CSS, and let the content fill it, not create it. - Never inject content above existing content. Cookie notices and promo bars belong at a fixed position or in pre-reserved space, not shoving the page down after load. - Tame font swapping. A fallback font swapping to a web font with different proportions shifts every paragraph. Preload the font and pick a similar fallback. Space reserved up front ~~~ ... /* the ad slot holds its ground even while empty */ .ad-slot { min-height: 280px; } ~~~ ### Which Metric Is Your Problem? Describe the symptom, get the diagnosis. Runs entirely in your browser. Interactive tool: https://ivig.dev/core-web-vitals-guide/ ### Where to Check Your Numbers - Search Console's Core Web Vitals report is the verdict that matters: field data, grouped into URL groups of similar pages, each group graded by its weakest metric. If you haven't set Search Console up yet, [my walkthrough](https://ivig.dev/google-search-console-setup/) gets you there in an afternoon. - PageSpeed Insights gives you both wells in one place: the field assessment up top (when CrUX has data for your URL), lab diagnostics below. Test your money pages individually, not just the homepage. - Your own phone, on mobile data, is the cheapest field tool there is. Open your site somewhere with two bars of signal and tap around. The 75th percentile visitor lives closer to that experience than to your office wifi. ### The Mistakes I Keep Finding on Audits - Chasing the lab 100. Weeks spent squeezing Lighthouse points while the field data already passed. The score that counts is the one from real users; past green, further lab polishing is hobby, not SEO. - Testing only on fast hardware. The site is judged at the 75th percentile of real visits, which means mid-range phones on mediocre networks. If you never test there, you're optimizing for an audience Google doesn't measure. - Lazy-loading the hero image. A performance plugin set to lazy-load everything, including the one image LCP times. Instant self-sabotage, two-minute fix. - Images without dimensions. The page assembles itself like a slow avalanche, and CLS collects the bill. Width and height attributes, everywhere, no exceptions. - The third-party graveyard. Five years of marketing tools, three still in use, all still loading. Every forgotten pixel is a tax on INP. - Fixing desktop while mobile fails. Assessments are segmented by device. The mobile assessment is usually the failing one, and usually the one with more traffic. - Declaring victory the same week. Field data is a 28-day window; the report catches up gradually. Verify with lab tools now, confirm in Search Console next month. ### The Core Web Vitals Checklist #### Run this against your key pages today - Field assessment checked in Search Console or PSI, mobile and desktop separately - LCP element identified on each money page, not lazy-loaded, fetchpriority set - Hero images compressed and served at honest dimensions - TTFB sanity-checked; caching or CDN in place if the server is the bottleneck - Width and height attributes on every image and video - Ads, embeds and banners load into pre-reserved space - Third-party scripts audited; unused ones removed, the rest deferred - Fonts preloaded with font-display: swap and a close fallback - Site tapped through on a real mid-range phone, on mobile data - Reminder set to re-check the field report after the 28-day window turns over ### Want Your Vitals Diagnosed, Not Just Measured? Tools tell you which number is red. Finding the one script, image or template block causing it is the actual work. Core Web Vitals are a standing part of my free review: I identify what's failing, why, and what I'd fix first, personally. [Request a free review](https://ivig.dev/#free-audit) ### Core Web Vitals: FAQ **Are Core Web Vitals a Google ranking factor?** Yes, modestly. Google says good vitals align with what its core ranking systems seek to reward. They're one signal among many: no rescue for weak content, but a real edge between comparable pages, and slow pages bleed visitors regardless of rank. **Why does PageSpeed Insights show 90+ while Search Console says Poor?** Different data. The PSI score is a Lighthouse lab simulation; Search Console grades real Chrome users over the previous 28 days. Google's docs say plainly that good lab data doesn't guarantee good real-user experience. The field assessment is the one tied to search. **What replaced First Input Delay?** INP, Interaction to Next Paint, stable since March 12, 2024. FID timed only the first interaction's input delay; INP measures interaction-to-frame for every click, tap and keypress across the visit, so it catches the sluggishness FID missed. **Why does my report show no data?** CrUX only publishes data for pages and origins with enough real traffic to report reliably and anonymously. Low-traffic sites show nothing, which means unmeasured, not failing. Keep fundamentals clean with lab tools; the report fills in as traffic grows. **How long until my fixes show in the report?** Field data is a 28-day rolling window, so the assessment improves gradually as new visits replace old ones. Search Console's fix validation runs its own 28-day session. Verify immediately in lab tools; expect the field verdict in about a month. **What are good LCP, INP and CLS values?** LCP within 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1, each at the 75th percentile of real visits, mobile and desktop graded separately. Poor begins at 4 seconds, 500 milliseconds and 0.25. --- ## Guide: Schema Markup Explained: What It Does for SEO and How to Add It URL: https://ivig.dev/schema-markup-guide/ Author: Milan Georgijevic Published: 2026-07-20 Updated: 2026-09-19 Schema markup is code, usually a small block of JSON-LD, that labels the content of a page in a shared vocabulary called structured data: this number is a price, this name is the author, this block is a review. Visitors never see it. Search engines read it, and it's what makes your pages eligible for rich results: the star ratings, product details, breadcrumbs and event listings that make a search listing bigger than two plain lines of text. I read structured data on every audit I run, and most schema advice online has two problems. Half of it is outdated, still promising rich results Google removed years ago. The other half oversells it as a ranking trick, which it isn't. So this guide stays honest about both: what schema does, what it stopped doing, and where it's still one of the best returns on an hour of work in technical SEO. 25% higher click-through rate on Rotten Tomatoes pages with structured data versus pages without Google case studies 82% higher click-through rate on Nestlé pages appearing as rich results versus plain listings Google case studies 35% more visits for Food Network after adding structured data to 80% of its pages Google case studies ### What Schema Markup Actually Is HTML tells a browser how content should look. It says nothing about what the content means. To a crawler, "4.8" on your page is just a string: a rating, a price, a version number, a shoe size. Schema markup removes the guesswork by labeling it explicitly. The vocabulary lives at [schema.org](https://schema.org/), a project Google, Microsoft and Yahoo launched together in 2011 so the whole industry would label things the same way. It has grown into a large dictionary: [823 types and 1,529 properties](https://schema.org/docs/schemas.html) at last count, covering everything from recipes to medical trials. You'll use maybe five of them. Here's a complete, working example. This block tells a search engine the page is an article, who wrote it, and when: A minimal JSON-LD block ~~~ ~~~ That's the whole trick. A script block of labeled facts, sitting invisibly in your HTML, saying in machine language what the page already says in human language. The two must match: Google's [structured data policies](https://developers.google.com/search/docs/appearance/structured-data/sd-policies) require markup to describe content that's visible on the page, and nothing else. ### What Schema Markup Does for SEO (and What It Doesn't) Let's kill the biggest myth first: schema markup is not a ranking factor. Adding it won't move you from position 8 to position 3. Google's own documentation frames structured data as a way to [understand page content and enable special result features](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data), not as a ranking signal. Anyone selling schema as a rankings lever is selling you something else. What it changes is presentation. Marked-up pages become eligible for rich results: the review stars, prices, cooking times, event dates and job details that expand a plain blue link into something bigger and more specific. Same position, more pixels, more information, more reasons to click. That's where the numbers in the tiles above come from. Rotten Tomatoes measured 25% higher click-through on marked-up pages. Nestlé measured 82% higher click-through on pages shown as rich results. Rakuten found users spending 1.5 times more time on pages arriving through them. The honest hierarchy looks like this. If your page isn't indexed, schema is irrelevant (my [indexing guide](https://ivig.dev/page-not-indexed/) comes first). If your content doesn't answer the query, schema won't rescue it. And if your [title and meta description](https://ivig.dev/on-page-seo-guide/) are a mess, fix those before decorating them. Schema sits on top of that stack: it makes a listing that already earned its position work harder for the click. ### Three Formats, One Sensible Choice: JSON-LD Google supports three ways to write structured data: JSON-LD, microdata and RDFa. The [official documentation](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) recommends JSON-LD, and for once the recommendation is also the practical winner. Microdata and RDFa weave attributes into your visible HTML tags, which means your markup is scattered across the template and every redesign risks silently tearing it. JSON-LD lives in one self-contained script block. You can read the whole thing at a glance, test it by copy-pasting into a validator, generate it from your CMS data, and update it without touching layout. Every block on this site is JSON-LD, and I haven't met a reason to use anything else on a new build in years. ### Rich Results in 2026: What's Left, and What Google Took Away This is where most schema guides quietly rot. Google has spent the last three years removing rich result types, and plenty of articles still recommend markup for features that no longer exist. The removals, with dates: - HowTo rich results: gone. Google [restricted them in August 2023](https://developers.google.com/search/blog/2023/08/howto-faq-changes) and removed them completely that September. - Sitelinks search box: gone. The search-within-a-site box driven by SearchAction markup [retired on November 21, 2024](https://developers.google.com/search/blog/2024/10/sitelinks-search-box), because usage kept dropping. - FAQ rich results: gone, and recently. The August 2023 change limited FAQ dropdowns to authoritative government and health sites. On [May 7, 2026, Google dropped them entirely](https://developers.google.com/search/updates#may-2026), for everyone. Any guide still promising FAQ dropdowns was written before that date. In each case Google said the same thing: leaving the old markup in place causes no errors and no harm. You don't need to rip it out. You just shouldn't build new markup for dead features, and you should read every "schema increases clicks" case study with the calendar in hand. Review features have their own restrictions: self-serving reviews of a LocalBusiness or Organization are not eligible for review stars, including embedded third-party reviews about your own business. Check [Google’s review policies](https://developers.google.com/search/docs/appearance/structured-data/review-snippet) before adding ratings. Several other supported features remain useful: #### Still shows in Google - Product snippets: price, availability, review stars - Review snippets on eligible types, subject to review policies - Breadcrumbs shown in place of the raw URL - Recipe cards with photos, ratings and times - Event listings with dates and venues - Job postings, video results, article info for news - Organization details feeding knowledge panels #### Retired by Google - FAQ dropdowns, fully removed May 7, 2026 - HowTo step-by-step results, removed September 2023 - Sitelinks search box, retired November 2024 - Any new markup built only to chase these features ### The Schema Types Worth Adding First You don't need 823 types. For most sites the whole practical vocabulary is six or seven types, and there's a sensible order to add them in: - Organization, on your homepage. Name, logo, URL, contact points, links to your real profiles. This is your identity card: it feeds knowledge panels and tells every machine reading your site who's behind it. If you're a local business with a physical address, use LocalBusiness instead; it inherits everything from Organization and adds address, opening hours, phone and map coordinates. - WebSite, on your homepage. Three lines that name your site and tie every page to one entity. Cheap and worth it. - BreadcrumbList, on every page below the homepage. Google replaces the raw URL in your listing with a readable path. Small, visible, and one of the few rich results almost any site qualifies for. - Article or BlogPosting, on posts and guides. Headline, author, dates, image. It connects content to authors and matters for Google News and Discover eligibility. - Product with Offer, if you sell things. Price, currency, availability, and review stars from real reviews. The most valuable visible rich result left: a listing with a price and stars against a competitor's bare link isn't a fair fight. - Person, for author pages. Job title, same-as links to real profiles. It helps machines connect your content to an actual human with actual expertise. - FAQPage, demoted to optional. The dropdowns are gone from Google, so don't add it expecting them. It's still a valid, harmless way to hand your questions and answers to machines in clean structure, which is why this page still carries one. View source if you're curious. ### Which Schema Does Your Page Need? Pick the page you're working on, get the stack I'd add to it. Runs entirely in your browser. Interactive tool: https://ivig.dev/schema-markup-guide/ ### Structured Data Examples: Add and Adapt JSON-LD The Organization, Article and Product examples below are starting points, not live business facts. Replace every placeholder, check the matching visible content and remove properties you cannot support. Do not copy example prices, authors, stock status or dates into a real page. The workflow is short, and it's the same whether you write the block by hand or let a plugin generate it: 1 #### Write the block Start from a template below or your CMS plugin. One JSON-LD script per entity, in the head or body. Fails when: values in the markup don't appear on the page 2 #### Validate it Paste the URL or code into Google's Rich Results Test before it ships. One missing comma kills the whole block. Fails when: JSON syntax errors, missing required properties 3 #### Monitor it Watch Search Console's enhancement reports as Google recrawls. Errors and warnings show up there per page. Fails when: nobody looks at the report again after launch If you're on WordPress, check what your SEO plugin already outputs before writing anything: Yoast and Rank Math both generate Article, Organization and BreadcrumbList markup out of the box, and a hand-written duplicate on top of it creates two conflicting blocks. For everyone else, here are the three templates I reach for most. Swap the placeholder values, keep the structure. Organization (homepage) ~~~ ~~~ Article (posts and guides) ~~~ ~~~ Product (shop pages) ~~~ ~~~ Add AggregateRating to the Product block only when your page visibly shows real reviews with real counts. We'll get to why in the mistakes section. #### How to Adapt These Examples Safely | Example | Replace and verify | Avoid | | --- | --- | --- | | Organization | Business name, official URL, logo and genuine profile links | A profile belonging to a different business or a logo URL that does not load. | | Article | Headline, named author, representative image, page URL and real publication/update dates | Changing datePublished during a refresh or describing a different article. | | Product | The actual item, SKU, currency, current offer and availability visible on the page | Invented ratings, obsolete prices or claiming an out-of-stock item is available. | For the Article example, start by comparing `headline` with the visible heading and `author.name` with the byline. Open the image URL. Check that `mainEntityOfPage` names this article, not the homepage. Then compare the dates with the published and updated dates readers see. Google's [Article documentation](https://developers.google.com/search/docs/appearance/structured-data/article) describes its recommended properties. #### A Simple Structured Data Debugging Workflow - Check syntax. A trailing comma or unescaped quotation mark can break JSON. Fix the reported location rather than adding another script block. - Check meaning. A valid string can still name the wrong author, price or page. Compare each important property with the visible page. - Check deployed output. Test the live URL, not only pasted code. A plugin may add another conflicting block after your edit. - Check the right tool. The Schema.org validator checks vocabulary; Google's Rich Results Test covers supported search features. Neither promises a particular search appearance. - Check representative templates. Test an article, a service page and a product only if those page types exist. Record what must remain correct when the CMS content changes. For a broader release checklist, pair this with the [published meta-tag checks](https://ivig.dev/on-page-seo-guide/#worked-example) and the [SEO audit workflow](https://ivig.dev/seo-audit-checklist/). ### Required vs Recommended Properties: Valid Isn't the Same as Shown Every rich result type in Google's documentation lists two sets of properties. Required ones are the entry ticket: per the [general guidelines](https://developers.google.com/search/docs/appearance/structured-data/sd-policies), items missing required properties aren't eligible for that rich result at all. Recommended ones raise the odds and the quality of what's displayed. Requirements depend on the feature. For example, [product snippets](https://developers.google.com/search/docs/appearance/structured-data/product-snippet) require a name and at least one of review, aggregateRating or offers; merchant listings have different requirements. So there are three gates, and passing one doesn't open the next. Your markup can be valid (the JSON parses), eligible (required properties present, policies met), and still not be shown, because Google decides per query whether a rich result appears. Its own documentation states that correct markup is no guarantee of display. I've seen site owners rewrite perfectly good markup five times chasing stars that Google simply wasn't showing for those queries. Validate, make sure you're eligible, then give it weeks, not hours, before concluding anything. The test tool's "valid" is a floor, not a promise. The Rich Results Test checks syntax and required properties. It can't check whether your content deserves the feature, whether policies are met in spirit, or whether Google will choose to show it. Green checkmarks mean you're in the game, nothing more. ### Testing Your Markup: The Three Tools That Matter - [Google's Rich Results Test](https://search.google.com/test/rich-results) answers the question you actually care about: does Google see rich result eligibility on this URL? Test by URL rather than by code when you can, because that also catches markup your CMS mangles on render. - [The schema.org validator](https://validator.schema.org/) checks your JSON against the full vocabulary, including types Google doesn't reward with rich results. Use it for Organization, Person and anything you're adding for machine comprehension rather than for stars. - Search Console's enhancement reports are the long-term monitor: supported enhancement types detected on your site, with issues for reported items, updated as Google recrawls. If you're not set up there yet, [my walkthrough](https://ivig.dev/google-search-console-setup/) covers it. For day-to-day checking while you browse, my free Chrome extension [TechSEO Inspector](https://ivig.dev/techseo-inspector/) includes a JSON-LD viewer that lists every structured data block on the page you're looking at, formatted and readable. It's how I check my own pages and my competitors' without opening view-source. ### Schema and AI Search: The Honest Version You'll find plenty of articles claiming schema markup is the secret to getting cited by AI Overviews, ChatGPT and Perplexity. Here's what the primary source says. Google's [documentation on AI features](https://developers.google.com/search/docs/appearance/ai-features) is direct: there are no additional requirements to appear in AI Overviews or AI Mode, and "there's also no special schema.org structured data that you need to add". No magic AI markup exists, and nobody outside these companies knows exactly what their retrieval systems weigh. That said, the boring version of the argument holds up. AI systems have the same problem crawlers always had: turning your pages into facts about entities. Who runs this site, what does it sell, who wrote this, when. Clean Organization, Person and Article markup answers those questions in a format built for machines, costs nothing once written, and is exactly what Google recommends keeping accurate and consistent with the visible page. Do that version. Skip anything sold as "GEO schema" with a promised citation rate, because that promise is ahead of any published evidence. ### The Mistakes I Keep Finding on Audits - Invented star ratings. An AggregateRating of 4.9 from 200 reviews, on a page with no visible reviews at all. This is the one that gets sites a manual action for spammy structured data, which removes rich result eligibility sitewide. If the reviews aren't real and visible, the markup doesn't exist. This rule has no exceptions. - Markup describing things the page doesn't show. Prices that differ from the visible price, opening hours from two years ago, an author the page never names. Google's policies require the markup to match what visitors see. - Duplicate, conflicting blocks. The theme outputs Organization, the SEO plugin outputs Organization, and someone pasted a third one in a widget, each with slightly different names and logos. Machines reading three versions of your identity trust none of them. One source of truth per entity. - A copied block with someone else's data still in it. I've found competitors' brand names, logos and URLs in live markup more than once, pasted from a tutorial or a competitor's source and never fully edited. Diff every value against your own page before shipping. - One broken comma, zero markup. JSON is unforgiving: a single trailing comma or an unescaped quote and the entire block is silently ignored. No error on the page, nothing in the browser, just markup that doesn't exist as far as Google is concerned. This is why the validate step isn't optional. - Structured data on pages Google can't index. Beautiful markup on a page that's noindexed or blocked in robots.txt does nothing. Indexing first, decoration second. - Dates frozen in time. A dateModified from 2022 on a page updated last month, because the markup is hand-written and nobody remembers it's there. If you can't maintain a property, leave it out. ### The Schema Markup Checklist #### Run this against your site today - Homepage carries one Organization (or LocalBusiness) block and one WebSite block - Every value in the markup appears on the visible page and matches it exactly - Articles carry Article markup with a real named author and honest dates - BreadcrumbList on every page below the homepage - Product pages include Offer with price, currency and availability - Ratings in markup only where real reviews are visible on the page - Exactly one block per entity: no plugin/theme/manual duplicates - Every template validated in the Rich Results Test, by URL - No new markup built for retired features: FAQ dropdowns, HowTo, sitelinks box - Search Console enhancement reports checked after the next recrawl ### Want to Know What Your Markup Says About You? Reading a site's structured data is part of every audit I run: duplicate entities, invented ratings waiting to become a manual action, broken JSON nobody noticed, and the types that should be there but aren't. Request the free review and I'll read yours personally. [Request a free review](https://ivig.dev/#free-audit) ### Schema Markup: FAQ And yes, this FAQ carries FAQPage markup even though the dropdowns are gone. The vocabulary is still valid, other machines still read it, and it costs nothing to maintain. **Is schema markup a Google ranking factor?** Not directly. Google's documentation frames structured data as a way to understand pages and make them eligible for rich results, not as a ranking signal. The measurable win is presentation: richer listings get clicked more, and Google's own case studies report 25 to 82 percent higher click-through rates on pages with rich results. **Should I remove FAQ schema now that the rich results are gone?** No need. Google dropped FAQ rich results entirely on May 7, 2026, but stated the markup can stay without causing problems, and FAQPage remains a valid schema.org type. Other search engines and AI systems can still read it. Just don't build new FAQ markup expecting dropdowns in Google, because that feature is finished. **Should I use JSON-LD or microdata?** JSON-LD. Google supports JSON-LD, microdata and RDFa but recommends JSON-LD because it lives in one script block, separate from your visible HTML. That separation means a template redesign can't silently break your markup, and you can read, test and update the whole block in one place. **How long until rich results appear after adding schema?** Google has to recrawl the page first, so expect days to a few weeks depending on how often your site gets crawled. And eligibility is not a guarantee: Google decides per query whether to show a rich result, even for perfectly valid markup. Track progress in Search Console's enhancement reports rather than refreshing the search results. **Can a plugin handle schema markup for me?** For the basics, yes. SEO plugins like Yoast and Rank Math generate solid Article, Organization and BreadcrumbList markup automatically. Check what your plugin already outputs before adding your own, because duplicate conflicting blocks are one of the most common schema problems I find on audits. Types beyond the basics, like Product or LocalBusiness with real detail, usually need manual work. **Do AI tools like ChatGPT read schema markup?** Treat claims here with suspicion. Google states plainly that no special structured data is needed to appear in AI Overviews or AI Mode, and most assistants work primarily from rendered page content. Clean markup still helps machines resolve who you are and what your pages contain, which costs nothing. Anyone selling schema packages that promise AI citations is ahead of the evidence. --- ## Guide: How Google Search Works: Crawling, Indexing and Ranking Explained URL: https://ivig.dev/how-google-search-works/ For a practical diagnosis after a page enters the index, follow the [indexed-but-not-ranking workflow](https://ivig.dev/indexed-but-not-ranking/). Publishing a page does not place it in Google. The page must be discovered, crawled, rendered, understood, selected for the index and matched to a search. These jobs are related but not interchangeable. A URL can be known but never crawled, crawled but not indexed, indexed but never shown, or shown for one query and invisible for another. Google describes Search in three broad stages: crawling, indexing and serving search results. For practical diagnosis, split the process into discovery, crawling, rendering, indexing and canonicalization, then ranking and serving. ### Discovery: Google learns that the URL exists Google has no central registry of web pages. It finds URLs mainly through crawlable links from pages it already knows and through XML sitemaps. Standard anchor elements with href attributes reveal destinations reliably and descriptive anchor text adds context. Clickable elements with only JavaScript handlers, form-only navigation and orphan pages can leave content difficult to discover. A sitemap is a discovery feed, not a replacement for navigation and not an indexing guarantee. It should contain the canonical, indexable URLs the site actually wants in search. ### Crawling: Googlebot requests the page After discovery, Googlebot may request the URL. The server returns headers, an HTTP status and usually HTML. A 200 makes content available, a permanent redirect sends the crawler to a new URL, a 404 says the resource is missing and a 5xx says the server failed. Crawling is scheduled rather than owed. Stable hosting, sensible URLs, internal links and the absence of crawl traps matter more to a small site than abstract crawl-budget optimization. Robots.txt can prevent fetching but cannot reliably keep a known URL out of search. A blocked crawler cannot see a noindex rule inside the page. ### Rendering: Google builds the page Static HTML usually contains the main copy and links immediately. JavaScript applications may send a shell and build the page after scripts run. Google renders pages with a Chrome-based system, but failed API calls, blocked resources, client-side routing, interaction-only content or lazy-loading mistakes can produce an incomplete rendered page. Titles, canonicals, structured data, main copy and important links should be stable in rendered HTML. Search Console URL Inspection can show rendered HTML and a screenshot, which is more reliable than assuming that a personal browser represents Googlebot. ### Indexing and canonicalization Google analyzes visible text, headings, titles, images, links and other signals. It groups duplicate or very similar pages and selects a canonical representative. Crawled does not mean indexed: a fetched page can be excluded because it carries noindex, duplicates another URL, points its canonical elsewhere, contains little distinct value or otherwise is not selected for separate storage. A canonical declaration is a preference, not a command. Google can choose another version when redirects, internal links, sitemaps and content contradict the declaration. ### Ranking and serving results When a person searches, Google retrieves candidates from its index and orders them for that specific query. A page has no single universal ranking. It may be competitive for one precise question, weak for a broad topic and irrelevant for another. Technical eligibility is the entry ticket, not the prize. A fast, indexable page with valid schema can still fail because it does not answer the search well. Strong content can also fail when a canonical points elsewhere or the server returns an error. Sustainable SEO connects content quality with correct implementation. ### Diagnose the pipeline from left to right 1. Confirm the URL resolves publicly and check its final status and destination. 2. Check robots.txt and robots meta rules. 3. Inspect the indexed URL and run a live test in Search Console. 4. Confirm the page has crawlable internal links and an appropriate sitemap entry. 5. Compare initial source with rendered content and metadata. 6. Confirm the declared and Google-selected canonicals. 7. Check whether the page offers distinct value rather than duplicating another URL. 8. Once indexed, use query and page data in the Performance report instead of relying on a site-wide average. ### Common misconceptions - Being discovered does not mean Google will crawl the URL. - Being crawled does not mean the page will be indexed. - Being indexed does not mean the page will rank. - Sitemaps suggest URLs but do not guarantee crawling, indexing or ranking. - Repeated indexing requests do not repair unchanged weak pages. - Schema cannot rescue blocked, duplicate or irrelevant content. - Google does not accept payment for more frequent crawling or higher organic rankings. ### Checklist The page has a crawlable internal link. Its canonical URL appears in the sitemap. It returns the intended response. Robots.txt allows crawling and there is no accidental noindex. Main content and metadata appear after rendering. Canonical signals agree. The page answers a distinct intent. Search Console confirms the expected selected canonical. ### FAQ **What are the three stages of Google Search?** Crawling, indexing and serving search results. Discovery and rendering happen inside the broader process. **Does Google crawl every page it discovers?** No. Discovery only means Google knows the URL exists. **Does crawled mean indexed?** No. A successfully fetched page may still be excluded as a duplicate, noindexed page or low-value URL. **Does indexed mean ranking?** No. Indexing creates eligibility. Ranking happens separately for each query. **How long does indexing take?** There is no guaranteed schedule. Hours are possible, but days or weeks are normal for new and lightly linked sites. **Can I pay Google to crawl or rank higher?** No. Organic crawling and ranking are separate from advertising. --- ## Guide: Canonical URLs Explained: What They Are and How to Use Them URL: https://ivig.dev/canonical-url-guide/ Author: Milan Georgijevic Published: 2026-08-13 Updated: 2026-09-19 A canonical URL is the representative version of a duplicate or very similar group of pages. If a product can be reached through its clean URL, a tracking parameter, a category path and a print view, search engines should not treat those as four separate pieces of content. Canonicalization helps them consolidate the group and decide which URL to show. The HTML used to suggest that preference is commonly called a "canonical meta tag." That name is convenient and technically wrong. It is a `` element with `rel="canonical"`, normally placed in the document ``. A real meta tag begins with ``, like the description or robots tag. Knowing the difference makes implementation and debugging much easier. ### What a Canonical URL Actually Does During indexing, Google groups pages it considers duplicate or very similar. It then selects a canonical: the page it considers the best representative of that cluster. Signals associated with alternate URLs, including links, can be consolidated toward the canonical, and Google generally shows the selected URL in search. Your declaration does not force that choice. Google's [canonical documentation](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) calls redirects and `rel="canonical"` strong signals and sitemap inclusion a weak signal. These can stack. Google can still select another URL when the pages are not actually similar or when your signals disagree. That distinction explains the two fields in Search Console: User-declared canonical is the URL your page or sitemap suggests; Google-selected canonical is the URL Google ultimately chose. A mismatch is not automatically an error, but it is evidence worth investigating. ### Why Websites Create Duplicate URLs Duplicate content is often a routing problem, not copied writing. One page can collect many addresses as platforms add tracking, sorting, filtering and alternate paths: - `https://example.com/shoes/blue-runner/` - `https://example.com/shoes/blue-runner/?utm_source=email` - `https://example.com/products?id=184` - `https://example.com/sale/blue-runner/` - `https://www.example.com/shoes/blue-runner` Other sources include HTTP and HTTPS versions, www and non-www hosts, uppercase and lowercase paths, trailing-slash variations, printer pages, downloadable formats, session IDs, faceted navigation, syndication and near-identical product variants. The issue is not a mythical "duplicate content penalty." The practical costs are divided signals, inconsistent reporting, wasted crawling and the wrong URL appearing in search. Canonicalization is for duplicates and close equivalents. Do not point unrelated or meaningfully different pages at one popular URL just to move authority. Google may ignore it, and you risk removing useful pages from the index. Before choosing an implementation, use the [duplicate content decision guide](https://ivig.dev/duplicate-content-seo-guide/) to decide whether the pages should stay separate, be combined or use one representative URL. ### How to Implement rel="canonical" Correctly Place one canonical link element inside the valid `` of every indexable HTML page: HTML head ~~~ ~~~ Use an absolute HTTPS URL including the preferred host and path. Relative canonicals are supported, but Google recommends absolute paths because a staging host, unexpected base URL or template reuse can turn a harmless shortcut into a sitewide error. #### Use a self-referencing canonical on the preferred page The clean page should point to itself, while true duplicate versions point to that same clean URL. Self-references make the preference explicit and protect against unplanned parameter variants. They also give automated crawlers and audit tools a simple expected state. 1 #### Choose one URL Decide the HTTPS host, case, path and trailing-slash format that should represent the page. Fails when: teams use different preferred formats 2 #### Align every signal Canonical element, redirects, internal links, sitemap and hreflang should agree. Fails when: one template or feed points elsewhere 3 #### Verify Google's choice Crawl the site, then compare declared and selected canonicals in Search Console. Fails when: validation stops at viewing source ### The Canonical Signals Google Uses Google publishes a useful order of influence. A redirect is a strong signal because the old URL no longer serves its own page. A `rel="canonical"` link annotation is also strong. Sitemap inclusion is weaker because a sitemap lists preferred URLs without explicitly mapping each duplicate. #### Signals that should agree - Permanent redirects point to the preferred URL - Every duplicate declares the same canonical - The canonical page self-references - Internal links use the canonical URL - Only canonical URLs appear in the sitemap - Hreflang references canonical language URLs #### Conflicts to remove - Canonical points to A while sitemap lists B - Redirect destination canonicals back to the source - Internal navigation links mostly to parameters - HTTP page canonicals to HTTPS but HTTPS redirects back - Two canonical elements name different URLs - Canonical target returns an error or noindex Consistency is more important than cleverness. If your canonical says one thing but every internal link, redirect and sitemap says another, you have made Google solve a contradiction. The [internal linking guide](https://ivig.dev/internal-linking-seo-guide/) explains how to audit those paths. Link to the URLs you want indexed, and keep only those URLs in your [XML sitemap](https://ivig.dev/xml-sitemap-guide/). ### Canonical vs Redirect vs Noindex These controls solve different problems: - Use a permanent redirect when the alternate URL should disappear for visitors and search engines. Old slugs, HTTP versions and retired duplicate pages belong here. - Use rel="canonical" when alternate versions must remain accessible but represent substantially the same content. Tracking parameters, print versions or the same product under several category routes are common examples. - Use noindex when a page may remain accessible but should not appear in search and there is no equivalent page whose signals should absorb it. Account pages, thin internal results and private utility screens often fit. - Use robots.txt to manage crawling, not canonical selection. Blocking a duplicate can prevent Google from seeing the canonical element on it. A canonical does not redirect a browser. Visitors can still open the alternate URL. A redirect does. If keeping the duplicate accessible serves no user purpose, a redirect is usually clearer and easier to maintain. See the [HTTP status code guide](https://ivig.dev/http-status-codes-guide/) for the redirect side of that decision and the [robots.txt guide](https://ivig.dev/robots-txt-guide/) for crawl control. ### How Canonicals Work in Common Situations #### Tracking and sorting parameters A URL with `?utm_source=newsletter` usually shows the same page as the clean URL, so both can declare the clean URL canonical. The same often applies to sort order. Filters are different: a filtered category may satisfy a valuable distinct search intent. Decide from the content and user value, not from the presence of a question mark. #### Products in several categories If the same product content appears under several category paths, choose a stable product URL and canonicalize alternate routes to it. Better still, make the stable URL the one your internal links use. Canonical tags should not compensate forever for an avoidably inconsistent architecture. #### Product variants Canonicalize color or size variants only when the pages are truly interchangeable. If each variant has unique availability, images, identifiers, content and search demand, separate self-canonical pages may be correct. A canonical is not a rule that every product family gets one URL. #### Pagination Do not canonicalize every page in a sequence to page one. Google's current [pagination guidance](https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading) recommends a unique URL and self-referencing canonical for each page. Page two contains different items and helps crawlers reach deeper content; it is not a duplicate of page one. #### Syndicated articles A cross-domain canonical can suggest that the original article should receive the consolidated signals, but publishers must implement it and search engines still decide. If you need certainty that a partner copy cannot appear, contractual noindex or removal is stronger than hoping a canonical is honored. ### PDFs, JavaScript and International Sites #### Canonical HTTP headers for non-HTML files A PDF has no HTML head, so you can send a canonical in the HTTP response: HTTP response header ~~~ Link: ; rel="canonical" ~~~ This is useful when an HTML landing page and downloadable document contain the same material. Google recommends choosing either the HTML element or HTTP header for a resource rather than maintaining both and risking conflicting values. #### JavaScript-generated canonicals Google can process canonicals injected by JavaScript, but its guidance is to put the canonical in source HTML when possible and prevent JavaScript from changing it. If the source cannot contain one, inject one clear value rather than shipping a source canonical that JavaScript later replaces. #### Hreflang and language versions International pages usually self-canonicalize within their own language and reference their alternates with `hreflang`. Do not canonicalize every translation to the English page, because that tells Google the translations are duplicates to consolidate. Google's guidance says hreflang pages should specify a canonical in the same language whenever one exists. The [hreflang implementation guide](https://ivig.dev/hreflang-seo-guide/) shows a complete three-language example, return links, x-default and validation checks. ### How to Test Canonicals Properly - Crawl the entire site. Export each URL, status code and declared canonical. Look for missing values, multiple values, chains, loops and targets outside the intended host. - Validate the rendered head. The canonical must appear inside a valid ``. Browser repair of broken markup can move elements into the body, where Google may ignore them. - Check every target. A canonical target should normally return 200, be indexable, contain equivalent content and self-reference. Do not point to a redirect, 404, noindex page or irrelevant category. - Compare internal signals. Count internal links to duplicate versus canonical URLs and inspect the sitemap. Fix templates at the source instead of accepting thousands of mixed URLs. - Use URL Inspection. Google's [URL Inspection documentation](https://support.google.com/webmasters/answer/9012289) explains the declared and selected fields. Inspect the indexed version, because the live test cannot predict Google's final canonical choice. My free [TechSEO Inspector](https://ivig.dev/techseo-inspector/) shows the canonical declared on any page alongside its indexability signals. That is a quick page-level check; a full canonical audit still needs a crawl because the dangerous patterns appear across groups of URLs. ### Canonical Mistakes I Keep Finding - Every page points to the homepage. This does not make the homepage stronger. It tells search engines that distinct content should be treated as duplicate and is commonly ignored. - Staging canonicals survive launch. A copied template keeps `staging.example.com` in the head and sends every production preference to a host that should never be indexed. - A single hard-coded canonical across templates. Hundreds of products all point to whichever URL the developer used while testing. - Canonical chains. Page A points to B, which points to C. Point every duplicate directly to the final canonical. - Mixed URL formats. HTTPS canonicals coexist with HTTP internal links, slash and non-slash versions, or inconsistent capitalization. - Canonicalizing genuinely different pages. Category, location or variant pages with distinct intent are collapsed because they share a template. - Using noindex and canonical together. One instruction says remove this URL; the other asks to consolidate it. Use the control that matches the goal. - Blocking duplicates in robots.txt. Google cannot fetch the page to see its canonical element, leaving weaker external clues to determine the cluster. - Trusting the tag without checking Google's choice. Clean source code is not the outcome. The selected canonical in indexed Search Console data is the outcome. ### Canonical URL Implementation Checklist #### Run this before releasing a template - Exactly one `rel="canonical"` appears inside the valid HTML head - The href is an absolute HTTPS URL using the preferred host and format - Every indexable canonical page self-references - Duplicate pages point directly to one equivalent preferred URL - The target returns 200, is indexable and has equivalent content - Internal links, redirects, sitemap and hreflang agree with the canonical - Paginated pages and distinct variants are not incorrectly collapsed - Search Console confirms the intended Google-selected canonical ### Are Your Pages Sending Mixed Canonical Signals? Canonical problems rarely live on one page. I trace templates, parameters, redirects, sitemaps and internal links together, then identify exactly where the signals split. Request a free website review and I will check the pattern, not just the tag. [Request a free review](https://ivig.dev/#free-audit) ### Canonical URLs: FAQ **What is a canonical URL?** A canonical URL is the representative URL for a set of duplicate or very similar pages. You can suggest it with redirects, a rel=canonical link element and sitemap inclusion, but search engines make the final selection. **Is a canonical tag a meta tag?** No. The common phrase is technically incorrect. The HTML implementation is a link element placed in the document head: . **Should every page have a self-referencing canonical?** For ordinary indexable HTML pages, yes, it is a useful best practice. It makes your preferred URL explicit and protects against accidental tracking or parameter versions. **Is rel=canonical the same as a redirect?** No. A redirect moves visitors and crawlers. A canonical leaves the alternate accessible while suggesting that search signals belong under a preferred URL. Redirect retired URLs; canonicalize useful alternate versions. **Can Google ignore a canonical tag?** Yes. It is a strong signal, not a command. Google may choose another URL when content, redirects, internal links, sitemaps or other signals contradict your declaration. **How do I check which canonical Google selected?** Inspect the indexed URL in Search Console and compare User-declared canonical with Google-selected canonical. The live test shows the declaration but cannot predict the final choice. Need to choose between keeping an alternate URL and moving its visitors? Read [Canonical Tag vs. 301 Redirect: Which Should You Use?](https://ivig.dev/canonical-vs-301-redirect/) for worked examples and a verification checklist. ---