Your robots.txt file must live at the root domain level—exactly at yourdomain.com/robots.txt or yourdomain.ca/robots.txt. This isn't negotiable. Google, Bing, and other crawlers are hardcoded to look only at this location when they first visit your site. If you place it anywhere else, like yourdomain.com/seo/robots.txt or in a subfolder, crawlers won't find it and will treat your site as if no robots.txt exists. This matters for subdomains too. If you run blog.yourdomain.com, that subdomain needs its own robots.txt at blog.yourdomain.com/robots.txt. The main domain's file doesn't apply to subdomains. Same logic applies if you operate multiple country-specific domains—each needs its own file at the root. When we audit sites at Ottawa SEO, we see this mistake surprisingly often: someone uploads robots.txt to /public, /wp-content, or a CMS-generated folder, then wonders why Google is indexing pages they meant to block. The fix is simple but requires server or CMS access. For WordPress, the file goes in the same directory as wp-config.php. For static hosts or CDNs, confirm your deployment pipeline puts it at the true root, not a build subfolder. One thing to verify after placement: check yourdomain.com/robots.txt in a browser to confirm it returns the file content, not a 404. Also test it in Google Search Console under the URL Inspection tool or the legacy robots.txt tester. If you're using a headless CMS or serverless setup, make sure your routing rules don't accidentally block or redirect the /robots.txt path. Keep the file small and focused. It's a plain text file, case-sensitive, and crawlers expect UTF-8 encoding. If your host forces HTTPS, both http://yourdomain.com/robots.txt and https://yourdomain.com/robots.txt should serve the same file or redirect cleanly. Location is non-negotiable, but maintaining a clean, up-to-date file at that location is what actually protects crawl budget and prevents indexation issues.