saying that a sitemap will affect all the child directories from where the file containing the sitemap is located.
I'm not a fan of that wording. It's basically saying that a sitemap can only contain URLs that are at the same level or lower in the URL-path structure from where the sitemap is served from. Most sites serve their sitemap from the root directory so can contain URLs that cover the entire domain. However, a sitemap returned from example.com/foo/sitemap
can contain example.com/foo/bar
and example.com/foo/bar/baz
, but not example.com/bar
- which is outside of the URL-path tree.
Don't get hung up on the word "file". As far as the user-agent (eg. Googlebot) is concerned that makes the request, it does not know from the response whether the request mapped directly to a physical file or not.
And "directories" is referring to URL path segments, not physical directories on the underlying filesystem (which the user-agent making the request knows nothing about).
But the problem is that I do not have a file per se, I have a controller that outputs an .xml when my route site.com/sitemap is called, so it's not an .xml, but rather a .php outputting an XML
That's perfectly fine. As mentioned above, the user-agent making the request can not tell the difference, since the HTTP response is likely to be the same.
Aside: The only potential issue might be if you are dynamically generating the sitemap on every request. This could be slow and resource intensive. The response should be cached server-side so it doesn't need to be generated on every request, only when your site has changed. (If the response is cached then you are "kind of" returning a "file", depending on how your caching works.)