dns

Attention over time

7-day rolling share of analyzed posts/comments mentioning this entity · 90 daily points ending 2026-08-28

Final complete day: 2026-08-28. Attention was 0.7% — this entity appeared in 19 of 2,594 analyzed posts/comments in the seven days ending that day (26 mentions).

Each point is a seven-day rolling window of complete UTC days; a point is comparable only when at least 100 analyzed posts or comments fall inside it. A day with no analyzed records counts as zero; missing coverage is marked and never shown as zero. The series ends at the latest complete analyzed day — it never extends into the current incomplete day. How attention is measured.

Recent mentions

1. 2026-08-28 21:44 UTCComment

   no need to apologise, that was on me. too much jargon. TTL is just "how long the internet remembers where your domain points". it's a setting in your dns, usually set to a day. change it to 5 minutes before you switch, and if something goes wrong you can undo it in 5 minutes instead of waiting a day. one dropdown, nothing to install. Redirection plugin is fine. skip .htaccess entirely. you can paste your rules in as a csv. order: nameservers, wait, ssl, change the wordpress address, search-replace, redirects, go live. and for what it's worth - this is a two or three day job for someone who does migrations for a living. you're doing it alone, for the first time, while running a journal. it feels impossible because it more or less is.

2. 2026-08-28 19:57 UTCComment

   the thing that unlocked this for me when i did a similar move: nameservers and redirects aren't really "which first", they're on different tracks. redirects live on the new host, so they physically cannot do anything until dns is already pointing there. but you write and test them before you cut over. order that works: 1. finish the site on the temp domain. don't touch dns while anything is still broken. 2. let the registrar transfer fully complete first. doing a transfer and a nameserver change at the same time is how people end up locked out for 48h with a dead site. 3. drop your dns ttl to 300 seconds a day or two before cutover. default is often 24-48h, and that's the difference between a 5 minute switch and two days of half your visitors hitting the old box. 4. build your 301 map now, on the temp domain. this is the big one for you - a decade old custom php site going to wordpress means basically every url changes (article.php?id=44 to a pretty permalink). for a peer reviewed journal those old urls are cited in other papers and indexed. if you lose that mapping you lose the citations. dump every old url, map each one to its new home, test them on temp. 5. content freeze on the old site, final sync. 6. point the nameservers. 7. ssl after dns resolves, not before. lets encrypt validates over http, so it can't issue until the domain actually points at greengeeks. 8. keep kualo alive and paid for another month. it costs you almost nothing and it's your rollback. also since the domain isn't changing, you do NOT need change of address in search console. just resubmit the sitemap after cutover and watch the coverage report. honestly the 20 pages of notes feeling is normal, the list above is really the whole thing. one step at a time.

3. 2026-08-28 19:57 UTCComment

   after. let's encrypt validates by fetching a file over the real domain, so the cert can only be issued once dns points at greengeeks. nameservers aren't the last step, they're second to last. the thing nobody mentioned: drop your dns TTL to 300 a day before you switch. default is often 24h, so if something breaks you're stuck with it for a day instead of five minutes. do it now, costs nothing. and your redirects can be written and tested today - relative paths in .htaccess don't care what the domain is. the old site also stays up during propagation, so you don't get a wall of 404s either way.

4. 2026-08-28 13:55 UTCComment

   You can hook up a script or an LLM to a browser-based tool like Chrome Devtools MCP or Playwright, render a sitemap of your entire site. Have it loop through every page and write the HTML of each page in a folder based structure with static HTML files. Then deploy that static copy to GitHub Pages, change the DNS so the URL points to the GH pages and done. How many pages is this for? Hundreds/thousands, I would invest some time in a proper pipeline that automates this. If it's more like 25 then I would just do it manually. There's options like which lets you manually download a webpage with all images, CSS, fonts, etc.. included into 1 HTML file.

5. 2026-08-28 06:45 UTCComment

   one angle nobody mentioned: personal projects outlive your willingness to pay for them. i had a paid host lapse once and the site plus every subdomain just went dark. moved the static parts to cloudflare pages (free tier, custom domain, no card required) and now the parts that cant "expire" are the parts that dont bill. so my rule: frontend on a free static host forever, backend on something that scales to zero, and dns at cloudflare so you can repoint pieces in one click when you inevitably move the backend. and +1 to the billing alert advice above, that one sounds earned