last.fm

Readiness by lane

Green: last.fm. Thin bar: Audio & Music Streaming peer median.

Priority fixes for last.fm

Ordered by impact and by how common each practice is among peers.

1. Priority 1 · Enable

   XML sitemap discoverable

   Observed: No sitemap was listed in robots.txt or found at /sitemap.xml.

   Why it matters: A sitemap helps search engines find new and updated pages, especially on large or frequently updated sites.

   What to do: Generate an XML sitemap of canonical URLs, reference it in robots.txt and submit it in Google Search Console.

   84% of Audio & Music Streaming peers do this. Limit: Only the standard location was requested, once, at the time of the check.

   Guide: XML Sitemap Guide: Include Only URLs You Stand Behind

2. Priority 2 · Accelerate

   Static files cached for 30 days or more

   Observed: A same-site stylesheet or script was cacheable for 1 hours, short of the 30-day benchmark.

   What to do: Give versioned (fingerprinted) CSS, JavaScript, fonts and images Cache-Control: public, max-age=31536000, immutable, and change the file name whenever the content changes.

   56% of Audio & Music Streaming peers do this.

   Guide: Browser Caching Guide for Website Owners

3. Priority 3 · Harden

   HSTS kept for at least a year

   Observed: Strict-Transport-Security was sent with a max-age of 0 days, below the one-year benchmark.

   What to do: Send Strict-Transport-Security on HTTPS responses. Start with a short max-age (for example 300 seconds), confirm every subdomain works over HTTPS, then raise it in steps to 31536000. Add includeSubDomains only when all subdomains are HTTPS. HSTS preload is optional and hard to undo; hstspreload.org itself does not recommend it by default.

   On Fastly: Add the header in VCL or a header rule as described in Fastly's HSTS guide.

   33% of Audio & Music Streaming peers do this.

   Guide: HTTPS and TLS Guide for Website Owners

4. Priority 4 · Harden

   DMARC policy enforces quarantine or reject

   Observed: The DMARC policy for last.fm was p=none, which asks receivers to take no action on failing mail.

   What to do: Publish DMARC with p=none and a reporting address first, fix any legitimate senders that fail SPF or DKIM alignment, then move to quarantine and finally reject.

   38% of Audio & Music Streaming peers do this.

   Guide: A Practical Website Health Check for Owners

What last.fm already does well

Practices fewer than half of Audio & Music Streaming peers use.

• Nameservers spread across providersNameservers spread across more than one operator.7.6% of peers
• Content Security Policy presentContent-Security-Policy present.18% of peers
• Reachable over IPv6IPv6 address published.41% of peers

What we saw

Homepage checked

https://www.last.fm/

Homepage response

HTTP 200

TLS

TLSv1.3, HTTP/2

Certificate

Sectigo, 198-day validity, expiring 2027-01-29

CDN or edge

Fastly, Google edge

DNS operators

4 self-run or other nameserver domains

HSTS

max-age 0 days

DMARC policy

p=none

Homepage HTML

59 KB, gzip

Images on homepage

8 (png 21, svg 2)

Limits: homepage only, one location, one moment. Header checks reflect the homepage response; other pages may differ.

Stack and providers

Seen in the homepage response, certificate and DNS. Provider pages compare how their customers configure the same checks.

All 31 checks

Select a gap for the method and fix. How each check works

Compare with other Audio & Music Streaming sites

• evan-musics.ir60
• onlineradiofm.in60
• saregama.com60
• tajmusics.com61
• trendybeatz.com61

Audio & Music Streaming readiness benchmark