RFC 1033 forbids the use of CNAME for the registered, apex domain. The apex domain is the main domain without subdomains, such as ‘example.com’.
CNAME affects subdomain email settings because MX and SPF cannot differ. Upcoming ANAME is flattened CNAME to just A/AAAA. Outsourced hosting can then be safe.
The www subdomain is not unnecessary. There are some useful aspects. If you are hosting elsewhere, you will need CNAME, as allowed for subdomain www.
RFC 9116: "The "Expires" field indicates the date and time after which the data contained in the "security.txt" file is considered stale and should not be used (as per Section 5.3)".
RFC 9116: "It is RECOMMENDED that the value of this field be less than a year into the future to avoid staleness."
Suggestion 1: The data contained in the "security.txt" file MUST expire on the date and time as in the "Expires" field, due to the desirability of an annual audit cycle.
Suggestion 2: For the one-off annual cycle check to work, the "Expires" field date and time is maximally 398 (366+31+1) days into the future, equal to the TLS Certificate Lifespan.
Suggestion 3: Annual audit requires a scheduled date on an office calendar; and customer requests cannot be dealt with if concentrated in one part of the year.
RFC 6797, 8.1: "If a UA receives more than one STS header field in an HTTP response message over secure transport, then the UA MUST process only the first such header field."
Strict Transport Security over secure HTTPS is called HSTS. The server header is only compliant, even if it is just a URL redirect, with a functioning HSTS security header.
Although browsers do not strictly enforce this rule above, the internet.nl tool tests that the URL is also the first URL over HTTPS for a security header to work.
With multiple HSTS header values - an application can also set a security header - strictly speaking, the first security header applies to the user agent (UA).
The internet.nl tool does test for an initial header in the initial server header area.
Web browser Chrome and the securityheaders.com tool, show values from application to server header level. The first value, starting from server header level, should be set.
Note: The securityheaders.com tool does not test and report correctly on rewrite to HTTPS and redirection.
General approach: Comply with proper initial reading of security headers from the server header(s), and note the interpretation of a subsequent value from an identical security header.
First rewrite the URL to HTTPS using the checkbox in the control panel, secondly set security header values, and finally, if applicable, (conditionally) redirect in the 301 or 302 way.
A server header requires sufficient settings before public Internet access can be used safely. And avoid the HSTS preload list without understanding its implications.
For search engines in general, a no-indexing statement is necessary to clean up. For deletion in Google Search, even re-registration of the domain may be necessary.
Note that robots.txt content - for more control over crawling - can block any processing by a search engine, such as the desired removal of search results.