The robots.txt file lives at the root of your domain: yourdomain.com/robots.txt. It's never in a subdirectory. If you're checking a subdomain like blog.yourdomain.com, the path is blog.yourdomain.com/robots.txt—each subdomain can have its own file. To view it, just type the full URL into your browser. If the file exists, you'll see plain text directives. If you get a 404 error, no robots.txt is present, which is fine for most small sites but risky for larger ones where you need control over crawl budget. You can also inspect robots.txt through Google Search Console under the Coverage or Crawl Stats sections, or by using the old robots.txt Tester tool if it's still available in your account. Desktop SEO tools like Screaming Frog, Sitebulb, or DeepCrawl pull the file automatically during a site audit. Browser dev tools won't show it by default, but a quick manual check in the address bar takes two seconds. Common mistakes we see: clients assume robots.txt is hidden in their CMS or hosting panel. It's not. WordPress sites often auto-generate one via plugins like Yoast or Rank Math, but you control it under Settings > Reading or via FTP. Shopify and Wix generate their own default robots.txt files you can't fully override, which becomes a headache if you need granular control. For custom setups, you upload or edit the file via FTP, cPanel, or your server config. At Ottawa SEO, we always verify robots.txt before launching a site or migration. A single stray "Disallow: /" line can deindex an entire domain. We've rescued three clients in the past two years who accidentally blocked Googlebot after a developer pushed a staging robots.txt to production. Check it on launch day, after every major deploy, and quarterly as part of technical audits. If your site is indexed but you can't find a robots.txt, that means it's returning a 404—which tells search engines "crawl everything," the same as an empty file.