Build a Personal Weblog With AI and GitHub Pages

Personal weblog restomod
Design	Early 2000s personal weblog
Engine	Python static-site builder
Hosting	GitHub Pages
Assistant	Claude Code, OpenAI Codex, or supported ChatGPT tools
Public source	https://github.com/chrisabraham/weblog
Companion article	Build a 2004 weblog with AI and GitHub Pages

A personal weblog restomod is a simple personal site with the manners and appearance of a 2003 or 2004 weblog and a modern static publishing system underneath. Chris Abraham describes his own weblog as an ICON 4x4 sort of rebuild: vintage bodywork, current chassis. This page is a living practical reference. For the story, examples, jokes and original human assignment, see Build a 2004 weblog with AI and GitHub Pages.

What the real weblog uses

As of October 17, 2026, chrisabraham/weblog uses a custom Python static builder, not Jekyll. Editable posts reside in src/posts/, wiki reference pages in src/wiki/, media in src/media/, and presentation in src/style.css. build.py produces static HTML, CSS and feeds under docs/. GitHub Pages publishes that generated folder. GitHub Actions regenerates it after changes and runs checks. GitHub Pages does not run Python server-side for visitors.

Fastest beginner path

Create a GitHub account and a public repository named YOURUSERNAME.github.io. Add a README. Never upload passwords or private journals.
Open Claude Code on the web or an authorized Codex coding environment, connect the repository and ask it to make a small Python-powered personal weblog with modern accessible HTML.
Have the assistant create the post sources, stylesheet, build.py and a GitHub Actions workflow that builds and deploys the generated static files. The beginner workflow should use the GitHub Pages artifact deployment actions, rather than copying the larger chrisabraham.net workflow unnecessarily.
Ask it to run the build, confirm that index.html exists in the output, test the links and show the changed files. Review its pull request before merging.
Open the repository's Settings → Pages and choose GitHub Actions as the deployment source for this workflow. Watch its run under Actions. Visit https://YOURUSERNAME.github.io/.
Write a first post. Ask the assistant to update the homepage and archive and redeploy. On a local checkout, use python3 build.py and python3 -m http.server 8000 --directory docs to preview when the generated output folder is called docs.

Using the alternative deploy from a branch setting is fine when the generated site is checked into the docs/ folder and a .nojekyll file prevents a second build. Do not combine the two deployment methods unless you understand which is responsible for publication.

Reusable first prompt

Build me a genuinely personal weblog that looks like 2003 or 2004, with a title, homepage of article excerpts, separately linked full articles, archives and an About page. Use a tiny Python 3 static-site generator, basic HTML and CSS, and no mandatory JavaScript. Put the editable source in src/ and generate a static folder suitable for GitHub Pages. Include an authorized GitHub Actions workflow to build and deploy that output. It must be accessible by keyboard, screen readers and narrow phone screens. Keep it readable in text browsers. Start with a single sample post and a concise README. Run and check the build and explain how to publish it. Ask before replacing content or making irreversible changes.

Optional: Cloudflare DNS and your own domain

Chris Abraham uses Cloudflare's free authoritative DNS for all five of his websites. That is DNS hosting, the address-book service that maps a name to web and email destinations; it is separate from both buying a domain and hosting the website itself. GitHub Pages works perfectly well without Cloudflare, and a YOURUSERNAME.github.io site can be launched without buying a domain at all. Cloudflare's dashboard makes records, subdomains and changes convenient to manage.

Get the GitHub Pages site working first. Buy an optional custom domain at a registrar you trust, then add the existing domain to a free Cloudflare account. Cloudflare Registrar is an option for supported extensions and offers registrations and renewals at cost; it is a separate service from free DNS.
Compare the DNS records Cloudflare imports against the old provider. Preserve email MX, SPF, DKIM and DMARC, verification TXT records and any other records essential to your existing services.
After reviewing records and any existing DNSSEC DS entries, change the nameservers at your registrar to the exact pair Cloudflare assigns. Follow Cloudflare's setup guide and wait for the domain to become active.
Set the intended custom domain in the repository's Settings → Pages. Configure Cloudflare to match the current GitHub Pages DNS documentation. The usual bare-domain setup uses GitHub's four published A IP addresses; a www subdomain gets a CNAME to YOURUSERNAME.github.io.
Start with Cloudflare's DNS only (grey-cloud) mode on the GitHub Pages records. Confirm correct GitHub domain ownership, HTTPS, redirects, live site links and functioning mail before considering orange-cloud proxying, caching, redirects or additional products.

Help me connect my GitHub Pages weblog to my custom domain using Cloudflare's free DNS. Identify my current domain registrar and all existing mail and verification records. Explain a safe nameserver change, show the GitHub Pages records needed, and verify domain mapping and HTTPS. Do not make any DNS or registrar changes without permission. Keep Cloudflare's optional proxy off until the direct site works.

For screenshots-free beginner guidance and a fuller explanation of the distinction between registration, DNS and hosting, see Build a 2004 weblog with AI and GitHub Pages.

Follow-up prompts

Publish a new post

Use the following text as my next weblog entry. Preserve my voice and factual claims, suggest corrections separately, and format it for my actual site's post format. Include a short homepage excerpt and a dedicated full article. Run the builder and link checks, then show me the change for approval. My text is: [PASTE ENTRY].

Change the design

Keep the vintage web personality and improve this one aspect: [DESCRIBE IT]. Keep HTML semantic, links underlined and visibly focused, type readable, and the layout responsive. Do not add a framework just to make one design adjustment. Show me a preview.

Inspect the restomod chassis

Audit the site for keyboard navigation, visible focus, semantic headings, alt text, contrast, screen readers, zoom, mobile reflow, reduced motion, text-only and no-JavaScript usage, plus broken internal links, feeds, canonicals, sitemap and appropriate schema. Note actual results separately from unverified guesses. Suggest Core Web Vitals and PageSpeed fixes without inventing scores or compliance certification. Fix issues with small explainable changes and add tests where helpful.

Which AI may actually change GitHub files?

Claude Code in the terminal can work in local repositories and run Git commands with the necessary permissions. Claude Code on the web can work in authorized GitHub repositories and prepare pull requests. Codex offers a coding workflow capable of working with GitHub repositories and proposing changes. Ordinary Claude chat can read selected GitHub repository files via the GitHub integration; that is distinct from Claude Code's write-capable workflow. Ordinary ChatGPT GitHub connection can be read-only; use Codex or an explicitly enabled write-capable workflow to publish. Always check actual available access and review changes.

The entirely optional persnickety checklist

Fast HTML that functions without JavaScript; responsive small-screen layout; local or system font fallback.
Keyboard access, visible focus states, screen reader navigation, meaningful alt text, reasonable contrast, zoom/reflow and reduced-motion support.
Lynx or another text-browser inspection; human usability tests rather than declaring automatic ADA or WCAG certification.
RSS 2.0 and Atom feeds, correct feed discovery, and optionally OPML subscriptions.
A sitemap, accurate canonical URLs, sensible title and description metadata and genuinely appropriate schema.org markup.
Small images with responsive sources, Core Web Vitals attention and measured PageSpeed improvements.
Documented Creative Commons licence for material you actually own and wish to share, with third-party rights excluded or identified.
Attribution for AI writing and art, archived original prompts where appropriate, public edits and corrections, link checking and automated build tests.

All of these are optional extensions to a small first weblog. A useful homepage and one published entry are a complete beginning. Chris' advanced system is an editorial experiment in public provenance, accessibility and good publishing plumbing, with the visual manners of the old web.

Official references

After the first publication

For recurring build verification, navigation, feeds, source-versus-generated files and GitHub Pages deployment, use Static weblog operations and publication checks. For attribution, original AI prompts, explicit post corrections and agent handoffs, see AI editorial provenance and agent handoffs. These are maintenance references; the beginner setup remains here.

The article Feed the whole post to the image model describes one image-making experiment. Before passing a complete article to an external model, check that no private client, family or third-party material is included without permission. Check the resulting illustration and add an accurate caption and alternative text.

Maintained as a Chris Abraham wiki entry; original narrative in Build a 2004 weblog with AI and GitHub Pages. This page may be updated as AI products or GitHub deployment methods change. Read its source and Git history to inspect revisions.

This page was last edited on October 17, 2026. AI writes and edits the wiki from Chris' prompts; the history shows every change.

Build a personal weblog with AI