Weekly SEO Workflow: A 120-Minute Pass That Ships Real Changes

A weekly SEO workflow is a fixed 90–120 minute pass: read Google Search Console (and optional analytics), decide at most five shippable actions, merge them into git as MDX or site files, then re-measure about two weeks later. Strategy decks and dashboard screenshots do not count as done.

This playbook is the same loop multi-site operators run by hand — and the loop PageSeeds Operator automates from the terminal. If you want the commercial model (annual license, unlimited local projects), see pricing.

What does a weekly SEO workflow actually include?

Strip the theater. A useful weekly pass has four phases:

| Phase | Time (approx.) | Output | |-------|----------------|--------| | Read data | 20–30 min | Shortlist of pages/queries that moved | | Decide ≤5 actions | 15–20 min | Ordered plan with keep/drop rationale | | Ship into repo | 45–60 min | Commits: content, titles, links, redirects | | Log + schedule review | 5–10 min | Paper trail + +14d GSC re-read |

Anything that does not end in a published change (or a deliberate “no ship this week” note) is research, not a workflow.

The unit of work is a merge that can affect Search Console later — not a Notion board full of “optimize page X someday.”

Why weekly beats monthly for lean teams

Monthly SEO rituals tend to grow into project theater: a big audit, a 40-item backlog, one heroic publishing week, then silence. Google Search Console rewards consistency more than intermittent heroics. A site that ships one tight improvement most weeks — a title/CTR fix, an internal link pass, a keyword cannibalization merge, a refresh of a decaying post — tends to keep the graph and freshness signals alive.

For founders and lean teams running multiple content sites (Astro, Next.js, TanStack Start, or any MDX-in-git stack), weekly is also a capacity control:

• You never start a 20-page rewrite you cannot finish.
• You re-check evidence before the next batch of guesses.
• You can rotate which property gets attention without abandoning the others.

Industry practice from Google Search Central guidance is the same boring truth: measure performance in Search Console, fix what the data shows, and give changes time to recrawl — not invent infinite keyword lists disconnected from your own queries.

How do you run a 120-minute SEO pass step by step?

Minute 0–25: Read the Search Console tape

Use a fixed window so week-over-week is comparable (many teams use 28 days; some prefer 7 days for high-traffic properties).

1. Open Google Search Console → Performance → Search results.
2. Export or scan Queries and Pages (clicks, impressions, CTR, average position).
3. Optionally pull Pages → Indexing for coverage issues (soft 404s, crawled-not-indexed, redirect errors).
4. If you use Microsoft Clarity, PostHog, or similar, glance at rage clicks and exit pages only for URLs already on the GSC shortlist — do not open a second rabbit hole.

Build a one-screen shortlist, not a novel:

LOSSES: pages with falling clicks / impressions (keep threshold honest for site size)
NEAR-WINS: queries positions ~8–20 with real impressions
CONFLICTS: same query → 2+ URLs (cannibalization candidates)
GAPS: high-impression queries with weak titles/snippets (CTR)
INDEX: important URLs stuck outside “Indexed”

Google Search Console is the court of record for what your site already ranks for. Ahrefs, DataForSEO, Semrush, and similar tools help with volume/difficulty research when you need a new topic — they do not replace your own query × page tape.

Minute 25–45: Decide at most five actions

Cap the plan. A weekly SEO workflow without a cap becomes an unbounded agency backlog.

Score candidates on impact × confidence × effort:

| Action type | When it wins | Typical ship surface | |-------------|--------------|----------------------| | Title / meta CTR fix | High impressions, low CTR, position already OK | Frontmatter + H1 alignment | | Internal link add | Strong page exists; orphan or underlinked target | MDX body + related blocks | | Cannibalization merge | Same query on 2+ URLs with real impressions | Content merge + 301 + link rewrite | | Content refresh | Decaying clicks on a still-relevant URL | Sections, examples, lastUpdated | | New draft | Winnable query with no good page | New MDX + internal links in | | Indexing fix | Important URL not indexed / wrong canonical | Config, robots, sitemap, noindex |

Hard rules for lean teams:

1. Prefer evidence from GSC over “I feel like this post is thin.”
2. Prefer fixes that ship this week over multi-week rewrites.
3. Require a human OK before redirecting high-click URLs.
4. Leave “nice ideas” on a parking lot list — they are not this week’s five.

If you need a full merge playbook for multi-URL queries, use How to Fix Keyword Cannibalization as the expansion of that single action type.

Minute 45–105: Ship into git / MDX

This is where most “SEO workflows” die. Dashboards stop at recommendations. Your weekly pass is only real when files change.

Work in the repository that powers the site:

• Edit MDX with frontmatter your build already understands (title, description, slug, date, lastUpdated, FAQ).
• Rewrite internal links in the same PR as redirects so you do not leave hop chains.
• Add redirects in host config (vercel.json, framework redirects, or CDN rules) when consolidating URLs.
• Open a pull request on GitHub (or merge direct if that is your ops model) so the change is reviewable and reversible.
• Deploy and confirm the URL returns 200 (or 301 where expected).

Repo-friendly content ops means the deliverable is a versioned file, not a Google Doc. For the broader philosophy of files-over-dashboards, see Repo-Friendly Content Ops Without Dashboard Bloat.

Validate as you go:

• No dual H1 / title mismatch on the primary query.
• Answer-first intro if the page is a how-to.
• FAQ blocks only when they match real questions.
• Internal links use natural anchors, not “click here.”

Minute 105–120: Report and schedule the closed loop

Write a short weekly note (commit message, PR body, or ops log):

Week of 2026-07-31 — site: example.com
Actions (5 max):
1. CTR: /blog/foo title rewrite (impr 1.2k, CTR 0.8%)
2. Links: 3 contextual links → /blog/bar
3. Merge: /old → /keeper (shared query "…")
Review window: 2026-08-14 GSC re-read on keeper + CTR page
Skipped: new pillar draft (parked; no capacity)

Calendar the +14 day re-read on the URLs you touched. Closed-loop SEO means next week’s shortlist includes “did last week’s ships move impressions/clicks/position?” If not, diagnose (indexing lag, intent miss, thin content, links still pointing at ghosts) before stacking more guesses.

What should a multi-site weekly cadence look like?

Operators running several properties should not invent a different process per brand. Use one loop, rotate attention:

| Cadence | What gets the full 120 minutes | |---------|--------------------------------| | Week A | Site 1 full pass | | Week B | Site 2 full pass | | Week C | Site 3 full pass + quick health on 1–2 | | Every week | Emergency: index spikes, broken deploys, major cannibal conflicts |

One annual license model that covers unlimited local projects only matters if the process is portable. The same GSC → decide ≤5 → git ship → report pattern scales; endless custom dashboards per client site do not.

How is this different from a dashboard SEO stack?

| Dashboard stack | Weekly execution workflow | |-----------------|---------------------------| | Rank tracker screenshots | GSC query × page decisions | | Infinite opportunity lists | ≤5 actions with a ship date | | Content scores without merges | MDX commits + redirects | | Agency status decks | PR + deploy + re-measure | | Tool sprawl (Surfer SEO, Clearscope, Frase, Jasper…) | Terminal + repo + Search Console |

Optimization platforms can still help with brief density when you write net-new pages. They do not replace the weekly ship. If the work never lands in git, rankings will not care how pretty the heatmaps were.

How does PageSeeds Operator fit this weekly SEO workflow?

PageSeeds Operator is built as the system of work for this pass:

1. Reads clicks, impressions, queries, and indexing signals from Google Search Console (optional analytics such as PostHog / Clarity).
2. Decides a short weekly plan — losses, near-wins, cannibalization, link gaps, CTR issues.
3. Ships research, writing, fixes, and merges into your repo, capped at up to five actions per weekly pass.
4. Reports what shipped and re-measures against Search Console about two weeks later.

It runs locally (CLI + agent), uses your API keys, verifies the $490/year license offline, and keeps content in your git history — not a hosted content portal. Read-only Search Console and site reports work without a license so you can inspect the gap first; the license unlocks the research / write / fix / merge work.

Requirements are honest: terminal comfort, Google Search Console access, and a Mac prebuild (Apple Silicon) or build-from-source elsewhere. That is qualification, not a hidden gotcha.

Prefer buying the annual license and running the pass yourself over another retainer? Start at Install and pricing.

Weekly SEO workflow checklist (copy this)

1. Open GSC Performance for a fixed window (7 or 28 days).
2. List losses, near-wins, multi-URL query conflicts, CTR weak spots, index issues.
3. Pick ≤5 actions; park the rest.
4. Ship in one PR: content, frontmatter, links, redirects together when related.
5. Deploy; verify status codes.
6. Log actions and set a +14d GSC review.
7. Next week: re-read before inventing new work.

Frequently Asked Questions

What is a weekly SEO workflow?
A fixed cadence that turns Search Console evidence into shipped site changes and later re-measurement — not a monthly brainstorm.

How long should the pass take?
Plan on about two hours per site once exports and repo paths are familiar. Cap actions so the clock stays honest.

What if I only have 45 minutes?
Do Read + Decide, then ship one high-confidence action (often a title/CTR fix or three internal links). Partial weeks still beat zero weeks.

Do I need paid SEO tools every week?
No. Google Search Console is enough for prioritization. Use Ahrefs or DataForSEO when you need volume/difficulty for net-new topics.

How does this relate to an SEO CLI?
An SEO CLI is the category of tools that run this execution loop in the terminal against your data and repo. PageSeeds Operator is one implementation of that category.

Want the weekly pass automated against your Search Console and git repo? Install PageSeeds Operator → · See pricing →

Related Articles

• SEO CLI: What a Terminal SEO Agent Is (and Is Not)
• How to Fix Keyword Cannibalization: Step-by-Step From GSC Data
• Repo-Friendly Content Ops Without Dashboard Bloat
• How Often Should You Publish Blog Posts for SEO? A Small Business Reality Check
• Content Refresh Service for Blogs: Revive Old Posts and Reclaim Lost Traffic
• Reddit SEO Guide: How to Use Reddit to Boost Your Search Rankings

Expertise: Written by the PageSeeds team building Search Console–driven weekly SEO execution for multi-site operators.