Keep a Weekly AI-Generated Website Up to Date

How a Weekly AI-Updated Website Works

Some small websites get new content every week. Examples are a weekly list of new remote jobs and a list of threads where founders can share a project. Another example is a page of topics that get more attention from developers. The research is the same every week. This makes it a good job for an AI agent (an AI program that does tasks on its own).

Publishing is the risky part. One bad run can replace a useful page with broken links, duplicate items or invented items.

This guide shows how to set up a weekly update that runs safely with no person watching it. The update has these steps:

1. A scheduler (a tool that starts jobs at set times) starts the job once a week.
2. An AI agent reads the rules of the site in prompt.md, does the research and updates a data file.
3. The agent moves the previous issue (the content of one week) to an archive file with its date.
4. A check script looks for errors in the new data. If the script finds an error, the job stops and the live site does not change.
5. The job saves the change in Git with a short summary.
6. The job sends the new files to the same project on the host, so readers keep one bookmark.

In short, keep the rules in prompt.md and the content in a JSON file. Let the agent edit only the data. Test the data with a script, and deploy (copy the files to the host) to the same project every week. Run the job by hand a few times before you schedule it.

Structure the Site So an Agent Can Update It Safely

Keep the files that change every week apart from the files that must never change. This folder layout works well:

weekly-remote-jobs/
├── prompt.md              update rules the agent follows
├── CHANGES.md             the agent's summary of the latest run
├── scripts/
│   └── check.mjs          validation that runs before every deploy
└── site/                  the folder that gets published
    ├── index.html         layout, never edited by the agent
    ├── app.js             renders data/current.json in the page
    ├── 404.html
    ├── data/
    │   └── current.json   this week's issue
    └── archive/
        ├── index.html     list of past issues
        └── 2026-08-03.json

The page loads data/current.json with JavaScript and shows its items. The agent edits only that file and the archive. Because of this, the change of each week stays small and easy to review. Also, a run cannot break the design, the navigation or the page paths.

The job publishes only the site folder. The rules, the check script and the change summary stay in the repository (the project folder that Git tracks).

Write the Rules in prompt.md

Put all the information that the agent needs in one file at the root of the project. Then the scheduled instruction can stay short (“read prompt.md and follow it”). You can also change the rules of one site and keep the schedule as it is. If you run several weekly sites, give each site its own prompt.md with its own sources, fields and limits.

This is an example for a list of remote jobs:

# Weekly New Remote Jobs in IT: update rules

## Goal
Publish 20 to 25 remote software and AI roles that were posted,
or visibly still open, in the last 7 days.

## Sources
- Company career pages and job boards that show a posting date.
- Link to the original posting, not to an aggregator search page.

## Fields for each item in site/data/current.json
title, company, location, salary (only if the posting states it),
url, posted_on (YYYY-MM-DD), notes (one sentence).

## Before you save
- Open every url and confirm it shows the job, not a search page.
- Drop items older than 7 days unless the posting is clearly active.
- No duplicates by url, or by company plus title.
- If you cannot verify an item, leave it out and say so in CHANGES.md.

## Archive
Before writing the new issue, copy site/data/current.json to
site/archive/<date of the previous issue>.json and add a link to it
in site/archive/index.html.

## Never
- Edit index.html, app.js, 404.html or any styles.
- Invent salaries, dates, companies or links.

## When you finish
Replace CHANGES.md with: items added, items dropped and why,
and anything you could not check.

Specific rules are more important than clever words. Write which sources the agent can use and which fields each item must have. Write the maximum age of an item. Also write what the agent must do when it cannot make sure that an item is correct. The rule “Leave it out and report it” keeps invented items off the page.

Add a Check Script

The agent can make mistakes even when the rules are good. For this reason, the job must not publish data that is clearly wrong. A short Node script finds most problems:

// scripts/check.mjs: stop the job if this week's data looks wrong
import { readFileSync } from 'node:fs';

const items = JSON.parse(readFileSync('site/data/current.json', 'utf8'));
const errors = [];

if (!Array.isArray(items)) {
  errors.push('current.json must contain a list of items');
} else {
  if (items.length < 10) errors.push(`only ${items.length} items`);
  const seen = new Set();
  const oldest = Date.now() - 8 * 24 * 60 * 60 * 1000;
  items.forEach((item, i) => {
    for (const field of ['title', 'company', 'url', 'posted_on']) {
      if (!item[field]) errors.push(`item ${i}: missing ${field}`);
    }
    if (item.url && !item.url.startsWith('https://')) errors.push(`item ${i}: url is not https`);
    if (seen.has(item.url)) errors.push(`item ${i}: duplicate url`);
    seen.add(item.url);
    const posted = Date.parse(item.posted_on);
    if (Number.isNaN(posted) || posted < oldest) errors.push(`item ${i}: posted_on is missing or too old`);
  });
}

if (errors.length) {
  console.error(errors.join('\n'));
  process.exit(1);
}
console.log(`ok: ${items.length} items`);

Change the fields and limits to match your site. When the script finds an error, it stops with an error code. Then the later steps of the job (commit, deploy) do not run.

Run the Update by Hand First

Before you schedule the job, run the same steps yourself and look at the result. To do this with Claude Code, run this command in the project folder:

claude -p "Read prompt.md and follow it to publish this week's issue. Edit files only." --allowedTools "Read,Edit,Write,WebSearch,WebFetch"

Codex has an equivalent non-interactive mode (a mode that asks you no questions), codex exec. It runs read-only (it cannot change files) unless you pass --sandbox workspace-write (Codex non-interactive docs). After the run, do these steps:

1. Read CHANGES.md and the diff (the list of changed lines, from git diff).
2. Run node scripts/check.mjs.
3. Start a local preview with python3 -m http.server 8000 --directory site.
4. Open http://localhost:8000 on a desktop screen and at phone width.
5. If the agent guessed something, make that rule in prompt.md more specific.

Do this for a few weeks. When a run needs no corrections from you, the job is ready to schedule.

ChatGPT scheduled tasks can run a prompt on a schedule and send you a notification. This works for a research draft that you then publish yourself. To publish with no person watching, you need a job with the project files, the check script and the deployment credentials. Deployment credentials are the keys for the host. A recurring reminder alone cannot do that work.

Schedule It with GitHub Actions

GitHub Actions can run the full job on a timer. The workflow (a file with the steps of the job) below uses the Claude Code GitHub Action for the research step. Then it deploys the site to Cloudflare Pages:

# .github/workflows/weekly-update.yml
name: Weekly update

on:
  schedule:
    - cron: "17 16 * * 1"   # Mondays at 16:17 UTC
  workflow_dispatch:         # also allows a manual run

permissions:
  contents: write
  id-token: write

concurrency:
  group: weekly-update
  cancel-in-progress: false

jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Research and update this week's issue
        uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Read prompt.md and follow it to publish this week's issue. Edit files only. Do not commit or deploy."
          claude_args: |
            --allowedTools "Read,Edit,Write,WebSearch,WebFetch"

      - name: Check the new issue
        run: node scripts/check.mjs

      - name: Save the change in Git
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git add -A
          git commit -m "Weekly issue $(date -u +%F)"
          git push

      - name: Deploy to Cloudflare Pages
        uses: cloudflare/wrangler-action@v4
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy site --project-name=weekly-remote-jobs --branch=main

Do these steps before the first run:

1. Install the Claude GitHub App on the repository, as Anthropic’s setup guide describes.
2. Add an ANTHROPIC_API_KEY repository secret (a stored key that the workflow can read). The default authentication of the action needs the id-token: write permission.
3. Create the Cloudflare Pages project one time with npx wrangler pages project create weekly-remote-jobs --production-branch=main. With this setting, deploys with --branch=main go to production (the live site).
4. Add CLOUDFLARE_ACCOUNT_ID and a CLOUDFLARE_API_TOKEN with the Account > Cloudflare Pages > Edit permission (Cloudflare CI guide).
5. Run the workflow one time from the Actions tab with Run workflow. Watch each step.

GitHub’s documentation gives these facts about schedules:

• By default, scheduled workflows run in UTC, on the latest commit of the default branch.
• When GitHub Actions is busy, runs can start late. This happens most at the start of every hour. A minute such as :17 avoids the busiest time.
• In a public repository, GitHub turns off scheduled workflows automatically after 60 days without repository activity.

Give the agent only the permissions that it needs. The example lets the agent read, edit and do web research only. It gives no shell access (no permission to run terminal commands). As a result, the agent cannot run commands, push code or change the deployment. If you prefer Codex, OpenAI recommends its openai/codex-action for GitHub workflows.

To publish on GitHub Pages instead of Cloudflare, replace the deploy step with the GitHub actions actions/upload-pages-artifact and actions/deploy-pages. Then select GitHub Actions as the Pages source (GitHub publishing source docs).

Review, Preview and Roll Back

A job that runs with no person watching can still get a review from you. You can review after the job publishes or before it publishes.

To review after the job publishes, read the commit and CHANGES.md every Monday. GitHub sends the notifications for scheduled workflow runs to the person who created the workflow. If a different person changed its cron schedule (the timer line) last, that person gets them (GitHub notifications docs).

To review before the job publishes, change --branch=main in the deploy command to --branch=review. Then Cloudflare publishes a preview deployment (a test copy of the site) at its own URL. Production does not change until you deploy to main (Direct Upload docs). Do not use preview URLs for private content. By default, preview URLs are public.

If a bad issue gets to production, roll back (go back to an earlier deployment). On Cloudflare Pages, open Deployments in the project. Open the menu next to the last good production deployment and select Rollback to this deployment (rollback docs). Then revert (undo) the commit in Git, so that the next run starts from good data.

Keep an Archive Readers Can Trust

Readers come back to weekly sites to compare issues. Keep the old issues available:

• Give each past issue a path with its date, such as /archive/2026-08-03. Do not reuse or rename that path.
• Use the home page only for the current issue. Show the issue date at the top.
• On the home page, add a link to the archive. On every archived issue, add a link back to the current issue.
• Add a 404.html page. Then an archive date with a typing error shows an error page, not the current issue.

Measure What Readers Use

On Cloudflare Pages, open the project and go to Metrics. Under Web Analytics, select Enable. Cloudflare adds the script on the next deployment (Web Analytics setup). Then you can see which pages get visits and where the visitors come from.

Wait several weeks before you make conclusions. If visits increase right after you automate the site, this does not prove that the automation caused the increase.

Common Mistakes

These mistakes are common:

• The agent edits the layout and the data in the same run.
• The job publishes all output from the agent, with no check script.
• The deploy depends on a reminder, or on a laptop that can be asleep.
• The API keys are in prompt.md or in the repository, not in Actions secrets.
• The agent has broad shell access, but it needs only to read, edit and browse.
• The page or archive URLs change from week to week.
• Nobody reads CHANGES.md, so nobody sees the dropped or unverified items.

A weekly AI-generated website stays useful when the rules, the data and the publishing steps are separate. Write the rules one time in prompt.md. Let the agent update only the data. Test the data before every deploy. Publish to the same project, so that the link does not change.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

• Publishes from GitHub on every push
• Works with Mintlify repositories
• API console from your OpenAPI file
• MCP server and llms.txt for AI agents
• Ask AI and support tickets
• Analytics for people and AI agents

Start Free→ Questions? Ask AI in our docs

No card required.