Public pages have a large audience
The website is designed to be reachable by anyone: buyers, search engines, researchers and automated scanners. Product APIs, by contrast, handle authenticated organisation actions and potentially sensitive content. Combining those surfaces makes the public site carry risk it does not need.
A static marketing site can remain simple: serve content, explain the product and direct evaluators to the right next step.
Documentation can still be useful
The public site can describe the shape of an API, error model or webhook contract without holding live credentials or making browser calls into customer environments. Exact OpenAPI definitions can be issued alongside an environment where version and authentication context are clear.
That keeps developer evaluation informative without turning the brochure into an application client.
Separation helps security review
When the public web host is not trusted to drive the product, security teams have a cleaner boundary to assess. A compromise of marketing content should not automatically become a path into organisation sessions or file operations.
The product may still link to sign-in, but that is navigation between trust surfaces rather than one surface pretending to be both.
Keep www outside the trust path
The marketing site can explain the product. Authenticated content actions belong on the product surfaces, not on the public website.