Decide what happens to contact, privacy and terms
Three pages from the old static site are indexed and now return 404. Decide whether the new site wants them.
Google is serving site:scofti.com results that include pages the current site
does not have. They are real, and they are from the version that came before
this one.
What the record shows: commit a99e624, 14 September 2026, "Wipe podcast
concept; reset to blank page", deleted contact.html, privacy.html and
terms.html along with the old hand-rolled index.html and
generate-sitemap.mjs. That was the day before the Next site was built.
All three now return 404, with and without the .html:
| URL | Status |
| --- | --- |
| /contact, /contact.html | 404 |
| /privacy, /privacy.html | 404 |
| /terms, /terms.html | 404 |
Nothing is broken. A 404 is the correct and honest answer for a page that is genuinely gone, and Google drops those URLs on its own once it recrawls. There is no redirect to write unless a replacement page actually exists — pointing a dead URL at the home page would be worse than the 404, because it claims the content moved somewhere it did not.
So this is a content decision, not a repair:
-
Contact. Probably wanted. The site consolidates ~28 domains into one address and currently offers no way to reach anyone. What form it takes is open — an address, a form, or the footer profile links doing the job already.
-
Privacy. Decided: the page is wanted. The weather strip was built as a server-side proxy specifically so Open-Meteo never sees a visitor's IP, and the jukebox loads nothing from YouTube until someone presses a strip. There is a real position to state, and it is about what happens to the reader — not about us.
The "no disclaimers" rule does not block it. That rule is about not volunteering that the site is built with AI. Of course it is; they all are now, and the domain registrars have been turning out mom-and-pop sites this way for years. Saying so would be the least interesting sentence on the site. A privacy page describing what the site does with a visitor's request is a different thing entirely.
-
Terms. Least obviously needed. The old one was boilerplate for a site that no longer exists.
Nothing should be written until the shape is decided.
Settled
Contact and privacy are built. Terms is dropped — boilerplate about a business that does not exist would be the first page here that is not really about anything.
Both are standing pages, so they sit in the footer and leave the index.
One correction came out of auditing the code before writing the privacy page,
and it is the reason the page is worth having: the site never sees a visitor's
IP address. The assumption going in was that it did. It does not — there is no
x-forwarded-for and no request.ip anywhere in src/. Vercel works out
approximate coordinates from the connection before any of this code runs, and
src/app/api/local/route.ts reads only those coordinates.
Four things the audit stopped from being published as written, each of which would have been false:
- "Nothing is stored." The forecast fetch sets
next: { revalidate: 600 }, so coordinates sit in a server-side cache key for ten minutes. The page says ten minutes, then gone. - "No cookies, ever." True of this code; not knowable for what Google sets inside a YouTube frame once a strip is pressed. The claim is scoped to the site, and the frame is named.
- "No logs." The site's own code logs nothing — zero
console.*insrc/— but Vercel keeps its own request records. The page says so. - "City-level coordinates." The code forwards Vercel's coordinates unmodified; their precision is not visible from here. The page says approximate.
A privacy page that overclaims is worse than no privacy page, so the last section says plainly what cannot be spoken for.