The robots.txt file itself is case-sensitive in its filename and location requirements. It must be named exactly "robots.txt" in lowercase and placed at your domain root (example.com/robots.txt, not example.com/Robots.txt or example.com/ROBOTS.TXT). Search engine crawlers won't recognize variants with different casing. The directives inside robots.txt have mixed sensitivity. User-agent, Disallow, Allow, Sitemap, and Crawl-delay are case-insensitive, meaning "User-agent" and "user-agent" work identically. However, the paths and URLs you specify in those directives follow your server's case sensitivity rules. Linux and Unix servers (the majority of web hosting) treat URLs as case-sensitive, so "/Blog/" and "/blog/" are different paths. Windows servers are typically case-insensitive for paths, but relying on this creates portability problems. This matters most when you're blocking or allowing specific directories. If you write "Disallow: /Admin/" but your actual URL is "/admin/", Linux-hosted sites won't block the lowercase version. At Ottawa SEO, we've seen staging environments accidentally exposed because a robots.txt blocked "/Staging/" but the actual path was "/staging/". Practical approach: always match the exact case of your actual URLs when writing Disallow or Allow rules. Use your browser's developer tools or server logs to confirm the precise casing of paths before adding them to robots.txt. For User-agent values, Google's crawler accepts "Googlebot", "googlebot", or "GOOGLEBOT" identically, but convention is to capitalize it as "Googlebot". Test your robots.txt in Google Search Console's robots.txt Tester tool, which shows exactly how Googlebot interprets your rules. If you're migrating between hosting providers or operating systems, audit your robots.txt because case sensitivity behaviour might change. The safest practice is to maintain consistent lowercase URLs across your entire site architecture, eliminating case ambiguity entirely for both users and crawlers.