Robots.txt must live at the root of your domain—https://example.com/robots.txt—not in a subfolder, not under /wp-content/, not anywhere else. Google, Bing, and other crawlers check this one location only. If you put it in /public/robots.txt or /assets/robots.txt, crawlers won't find it and will assume you have no directives. For most hosting environments, the root directory maps to a specific folder on your server. On Apache shared hosting that's usually public_html. On Nginx it's often /var/www/html or /usr/share/nginx/html. WordPress users upload it to the same folder as wp-config.php. If you're on Shopify or another managed platform, you typically edit robots.txt through their admin interface since you don't have raw filesystem access. You can verify placement by visiting yourdomain.com/robots.txt in a browser—if it loads, it's correct. Then validate it in Google Search Console under Indexing > robots.txt to catch syntax errors. Common mistakes include leaving a default Disallow: / from a staging site, blocking /wp-content/ which hides CSS and JS Google needs to render pages, or forgetting to add your XML sitemap reference. One robots.txt file governs the entire domain. If you operate multiple subdomains like blog.example.com or shop.example.com, each needs its own robots.txt at its own root. You can't use one file to control crawling across subdomains. For subdirectories like example.com/en/ and example.com/fr/, one root-level file handles both. At Ottawa SEO we audit robots.txt in every technical SEO review. We've seen clients accidentally block their entire site for months because a developer left a staging directive live. Always check after any migration, CMS update, or hosting change—robots.txt can be overwritten or lost. Keep a backup and monitor Search Console for unexpected crawl drops.