Hermes Agent for SEO: from Search Console to a blog post

I don't want an AI agent to turn a keyword into another 1,500 words of plausible advice. I want it to inspect the site, find a question worth answering, read the relevant documentation, and give me an article whose claims I can check. Hermes Agent plus Google Search Console gets you part of the way there. Add reusable research and writing skills, your repository, and your own technical notes, and you have a workflow you can inspect instead of a conversation you hope went well. This tutorial covers installation, connecting Google Search Console, and using short skill commands to research, write, or audit an article. It adapts the process behind my work at Straffe Sites. Contents What you are connecting Install Hermes for your operating system Connect Search Console through gcloud Adapt the marketing skills for Hermes Turn the setup into an article Check the draft before you publish Troubleshooting before you blame the model What you are connecting There are three separate pieces: Piece Job What it does not provide Hermes Agent Runs the conversation and tools; reads files; follows skills A Google account or verified technical expertise Google Search Console API Returns search performance for properties you can access Market-wide keyword volume or an explanation of why rankings changed NotFair's open-source skills Supply research, audit, planning, and writing procedures An automatically working replacement for their default hosted connector You ask for a task; Hermes loads the relevant skill, uses the connected tools, and returns an audit or draft for you to review. The skill carries the detailed procedure, so your chat message can stay short. Your Google credentials stay in the local setup, but content passed to a cloud model may reach that model provider. Use approved accounts, keep credentials out of chat, and only share client data you are allowed to process. You will need Git, a model provider configured in Hermes, and a Google account. You or your administrator must be able to approve Cloud setup and access to the intended Search Console property. Hermes can help select or create the Cloud project instead of making you configure it in advance. The Bash examples below target Linux, macOS, and WSL2 on Windows. Install Hermes for your operating system Linux and Apple Silicon macOS The official Hermes installation guide provides this CLI installer: curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash That executes a downloaded installer with your user's permissions and installs dependencies. If you prefer to review it first, use this route instead: curl -fsSL https://hermes-agent.nousresearch.com/install.sh \ -o hermes-install.sh less hermes-install.sh # Run only after reviewing the script and its dependencies. bash hermes-install.sh Open a new terminal if hermes is not yet on your PATH. Then verify the CLI and run setup in the default Hermes profile: hermes --version hermes setup hermes skills list In setup, choose your model provider and follow its authentication flow. Hermes installation and access to a model are separate requirements. The current platform support page lists Apple Silicon macOS as supported and Intel macOS as unsupported. Check that page before assuming an older Mac has the same installation path. Windows For the Bash examples in this article, use WSL2. In an administrator PowerShell window: wsl --install Restart if Windows requests it, open the installed Linux distribution, complete its initial user setup, and run the Linux installer above inside that shell. Have Hermes install Google Cloud CLI inside WSL too. Mixing a Windows Hermes process, WSL credentials, and Bash paths makes authentication harder to diagnose. Hermes also has an official native Windows installer. If you prefer PowerShell rather than WSL: iex (irm https://hermes-agent.nousresearch.com/install.ps1) Review that script first if you would not normally execute a remote installer. Native Windows installation is an alternative, not an extra step after WSL. The remaining shell snippets here are Bash; don't paste them unchanged into PowerShell. The Google setup prompt below asks Hermes to handle installation and paths for your actual environment, including native Windows. For an introduction that also covers the desktop app, see installing Hermes on Voltti. Use the official Hermes docs for current commands. Connect Search Console through gcloud Open Hermes: hermes Replace [MY_WEBSITE] with your site and give Hermes this prompt: Install gcloud and connect Google Search Console for [MY_WEBSITE] using a service account. Add its email in GSC through browser control, or give me the email to add myself. Use read-only access, ask me to approve permissions, and test the connection. Hermes can work out the installation commands, Cloud project setup, and authentication details from the official documentation. You handle Google login, consent, and 2FA. If browser control is unavailable, a Search Console property owner can add the email under Settings → Users and permissions. Restricted access is enough for performance reports. Keep command approvals enabled. Prefer keyless service-account authentication, keep credentials out of chat and your repository, and don't grant site ownership or broad Cloud administrator roles just to read reports. The connection test must use the service account that was added to GSC, not a different personal account. You should finish with the correct property identified and a real API read, not just “setup complete.” If the property has no useful history yet, Hermes should say so. My Search Console setup guide covers creating and verifying the property itself. Adapt the marketing skills for Hermes The NotFair plugin provides reusable SEO, research, and writing procedures. Ask Hermes to adapt them to the Google connection you just set up: Adapt the SEO and Search Console skills from https://github.com/nowork-studio/notfair-plugin for Hermes. Use my gcloud service account instead of the hosted connector, name them notfair-*, and keep Google access read-only. Show the changes and test results before installing. Hermes should inspect the source, include the required supporting files, and test the adaptation. You don't need to dictate the folder structure or API implementation. Review what it changed; once you are satisfied, reply: Install the reviewed skills. The notfair-* names below are the local names requested in that prompt, not commands bundled with a fresh Hermes install. Start a new Hermes session after installation. If a command is missing, ask Hermes to check that the skill was installed and exposed under its intended command name. Voltti's guide to retrieving marketing data with an AI agent explains the broader approach. Here, the goal is simply to make the skills use your own working Google connection. Turn the setup into an article In the Hermes chat box, start with /skill-name, then add a URL and what you want done. Type / to see available commands. Hermes loads the installed skill's instructions for you; you don't need to paste its whole procedure into the conversation. These examples go into Hermes chat, not Bash or PowerShell. I use Straffe Sites URLs as examples. Replace them with your own site; a public URL does not grant access to its private Search Console data. Each block below contains the original prompt and the complete final answer from a recorded Hermes run. Intermediate tool activity is omitted. The writing follow-ups continue the same writing conversation; the audit follow-up continues its own audit conversation. Nothing was published. DEV currently labels these compatible trace imports as Claude Code. The agent that ran them was Hermes. Expand the longer answers and use the scrollbar to read them. DEV does not create section anchors inside these embeds, so an answer's contents links will not jump to its headings. Write an article The skill supplies the writing process. Your prompt supplies the site and topic. Add an audience or angle when it matters, and let Hermes ask for anything it cannot establish from the context. Hermes Agent: writing Astro vs WordPress (compatible trace import) gpt-6-astra You /notfair-content-writer https://straffesites.com Write an English article about Astro versus WordPress for small business websites. Agent Blog article: Astro vs WordPress: choose for the person editing SEO metadata Title tag: Astro vs WordPress: choose for the person editing Meta description: Astro vs WordPress for small business websites: compare editing, speed, maintenance, and integrations. Use a practical checklist to choose your setup. Proposed URL slug: /en/blog/astro-vs-wordpress Target keyword: Astro vs WordPress Secondary keywords: Astro for small business websites; WordPress for small business; Astro CMS; WordPress vs static website. Search intent: Commercial investigation, answered through an educational comparison. Audience: Developers advising small businesses and owners evaluating website proposals. Content angle: Choose the editing and maintenance workflow first, then test the complete implementation. Metadata checks: Title: 49 characters. Description: 150 characters. Editorial research and positioning Existing coverage and keyword evidence No dedicated Astro-versus-WordPress article was found in the inspected content inventory or site search. Related coverage already exists: A website without a CMS: the site's Astro and Git content workflow. Astro vs. Next.js: framework selection. WordPress maintenance: ongoing operational work. What is a headless CMS?: separating editing from presentation. This draft keeps its focus on small-business platform selection rather than repeating those implementation guides. The verified keyword registry uses final Google Search Console data for sc-domain:straffesites.com, covering September 1, 2025, through September 1, 2026. It contains no retained query combining “Astro” and “WordPress.” The proposed primary keyword therefore comes from the requested topic and live search research, not a demonstrated ranking opportunity in that registry. Relevant existing queries include: Existing destination Recorded query Clicks Impressions Headless CMS article what is a headless cms 0 106 WordPress maintenance article wordpress development and maintenance 0 182 Astro glossary entry astro framework 0 11 These are query impressions for this property and period, not search volumes. The low-click clusters are indicative, and absent queries do not establish absent demand. Search-result review The first five returned results included: Result Format and emphasis Editorial response Web Aloha Broad comparison with performance, security, and cost claims Explain caching and avoid treating platform defaults as guaranteed outcomes. Reddit discussion Community discussion about editing and maintenance ownership Full discussion unavailable: extraction failed and the browser showed a human-verification page. No anecdote from it is used as evidence. Andrew Walpole Developer perspective on custom brand sites and content architecture Bring the decision down to small-business editing tasks and handover requirements. MFB Solutions Small-business comparison favoring Astro Correct the implication that static delivery eliminates technical maintenance. Dizzi Digital Business-purpose comparison and migration discussion Add a concrete acceptance test for editing, publishing, integrations, and recovery. Technical claims below rely on official documentation rather than competitors' benchmarks. The business scenario is explicitly hypothetical. No speed experiment, client result, or ranking uplift is invented. Content Astro vs WordPress: choose for the person editing Astro vs WordPress is often sold as a speed contest. For a small business, the more expensive mistake may be choosing a site that nobody can update. Choose Astro when a developer will maintain a mostly informational site; choose WordPress when the business needs a familiar publishing dashboard or depends on established plugins. A fast homepage cannot compensate for an outdated service page. This comparison is for developers advising small businesses and owners reviewing their recommendations. WordPress here means the open-source CMS in a conventional hosted setup, not a particular WordPress.com plan. Astro means the web framework, with static delivery as the starting point rather than a restriction. Contents Astro vs WordPress: the practical comparison Test editing before choosing the stack Compare finished pages, not framework promises Account for maintenance on both sides Check forms, bookings, and checkout early Use headless WordPress only for a specific reason Work through a small-business example Decide whether a migration is worth doing Frequently asked questions Astro vs WordPress: the practical comparison WordPress combines content management with website rendering. Its block editor gives editors a browser interface for headings, images, paragraphs, and other content. Themes control presentation, while plugins can add features. Astro is a framework for building the website. It does not supply an equivalent editorial dashboard by itself. Developers can use content files, connect a CMS, or combine sources. Its default rendering mode builds pages ahead of time; routes that need fresh or personalized responses can render on demand with an adapter and suitable runtime. Decision Astro, starting with static pages Conventional WordPress Who changes content? A developer, or editors using a separately configured CMS Editors using the built-in dashboard How do visitors receive pages? Prebuilt HTML for static routes; server rendering where configured Generated pages or cached responses, depending on the setup How are features added? Components, integrations, external services, or custom code Core features, plugins, external services, or custom code What needs maintenance? Dependencies, build and deployment workflow, hosting, accounts, and integrations Core, themes, plugins, hosting, database, accounts, and integrations Where does it fit well? Content-focused sites with deliberate control over the frontend Sites that benefit from an established editor and plugin workflow Neither column describes a maintenance-free product. Compare the complete setup the client will receive, including the editing interface and support arrangement. Test editing before choosing the stack Ask the eventual editor to do real work Before approving a platform, ask the person who will maintain the content to change opening hours, replace a photo, and publish a service update in a preview environment. Give them the proposed interface, not a presentation about it. Watch where they need help. Can they preview the page on a phone? Can they correct a mistake without contacting the developer? Can another employee take over? A technically elegant setup fails this test if routine changes require skills the business does not have. WordPress supplies the basic editing interface. Its usability still depends on the theme, blocks, permissions, and customizations. A cluttered dashboard with unrestricted layout controls can be harder to use than a small set of well-designed fields. Make Astro's content workflow explicit An Astro proposal should name the content workflow: developer-managed files, a Git-based editor, or a headless CMS. These are different products for the business, even when visitors receive similar HTML. Straffe Sites provides a concrete example of the file-based option: its website without a CMS uses Astro Content Collections with MDX and JSON content in Git. That demonstrates a workable approach for a technical team. It does not show that a shop owner should learn Git to change holiday hours. If editors need a CMS, include it from the start. Agree on preview access, publication timing, image handling, and who responds when an update fails. Choose the editing workflow before treating Astro as the finished solution. Compare finished pages, not framework promises Astro provides useful defaults, not a guaranteed score Astro's islands architecture lets developers render UI components as HTML and add client-side JavaScript where interactive components need it. A service page can remain mostly HTML while a calculator receives its own interactive code. That can reduce unnecessary browser work. It does not make large photos smaller by itself, remove an embedded booking widget, or stop a developer from adding expensive scripts. Ordinary script tags and third-party embeds still count toward the visitor's workload. WordPress is not required to rebuild every public page for every visitor. Its official caching documentation describes serving cached static files. A well-configured page cache changes the comparison substantially; dynamic and personalized pages need separate consideration. Agree on a fair test Compare representative pages with the content and features the business will actually use. Include the same images, fonts, analytics, and booking tools. Test a service page and an article, not just a nearly empty homepage. Check loading behavior and responsiveness on mobile, keyboard navigation, layout stability, and whether the main action works. Record the test conditions. Lab tests help diagnose problems; available real-user data describes a different population and should not be presented as the same measurement. Google confirms that Core Web Vitals are used by its ranking systems, but good scores do not guarantee top rankings. Neither platform replaces useful content, crawlable links, or accurate service information. This article reports no controlled Astro-versus-WordPress experiment, so it makes no percentage-speedup or ranking-uplift claim. The acceptance criterion should be a usable, measured website, not the framework name on the proposal. Account for maintenance on both sides WordPress maintenance has a familiar shape WordPress needs a plan for core, theme, and plugin updates, backups, access control, and recovery. Its security guidance describes security as risk reduction rather than risk elimination. Managed hosting can take responsibility for some tasks; check which ones the agreement actually covers. Test important functions after changes. For a service business, a working contact form matters more than a dashboard that says every plugin is current. The separate guide to WordPress maintenance covers the work in more detail. Static delivery removes some responsibilities, not all of them A fully static Astro frontend does not need a WordPress application or database to serve its pages. Removing that public application layer removes the need to maintain it. But the repository, dependencies, deployment accounts, domain, and hosting still need care. Forms, APIs, and any connected CMS bring their own responsibilities. A compromised deployment account can replace a static site. A broken dependency can prevent the next build. If the site uses on-demand rendering, its runtime also needs maintenance. “Nothing to patch” is not a credible handover promise. Compare ownership costs across the same scope: implementation, hosting, editor support, integrations, updates, recovery, and eventual handover. Do not compare basic static hosting with a WordPress agreement that also includes technical support. Ask who owns each task and what happens when that person is unavailable. Check forms, bookings, and checkout early A static page can display a form, but submitting it still needs a receiving service or server endpoint. Choose that destination before launch. Test validation, spam controls, delivery failures, and the confirmation message. A success screen should mean the receiving system accepted the request, not merely that the visitor clicked a button. For appointments, distinguish a link to an existing booking service from a custom booking application. A local consultant who already uses a scheduling service may need only a clear link. A business managing staff calendars, deposits, cancellations, and customer accounts has a larger integration problem. The same distinction applies to selling online. WordPress can use a commerce plugin such as WooCommerce. Astro can connect to a commerce backend, but the framework itself is not an order-management system. Define who handles products, inventory, payments, refunds, and customer notifications before selecting the frontend. List the business operations first. If an established WordPress plugin already supports them well, replacing it with custom integrations needs a specific benefit. If the business already runs those operations in another service, its website may not need to duplicate them. Use headless WordPress only for a specific reason Astro and WordPress can work together. In a headless setup, WordPress manages content while Astro renders the public website. The official Astro integration guide explains how to retrieve content through the WordPress REST API. This is useful when editors need to retain WordPress while developers need a separate frontend. The guide to how a headless CMS works explains that separation more broadly. It also leaves two systems to operate. For a statically built frontend, publishing in WordPress must trigger a successful build and deployment before visitors see the new content. Draft previews, failed builds, redirects, and cache invalidation need deliberate handling. WordPress plugins that expect to render their own frontend do not automatically become Astro components. Keep private drafts behind appropriate authentication. Treat HTML returned by a CMS according to its trust boundary; rendering a string as HTML is not a substitute for controlling who can supply it. Choose this combination to preserve a valuable editorial workflow or meet a frontend requirement. It is usually unnecessary complexity if a conventional WordPress site already does the job. Work through a small-business example Consider a hypothetical electrical contractor with eight service pages, a project gallery, a contact form, and an existing external scheduling tool. The owner changes service descriptions occasionally and wants someone else to handle technical maintenance. These are example requirements, not a client case or measured experiment. Astro is a reasonable starting point. The service pages can be prebuilt, the gallery can use optimized images, and the booking action can link to the scheduling tool. The proposal still needs to explain how the owner requests content changes and how urgent corrections are handled. Now change one requirement: an office manager must publish new projects independently every week. Astro can still work, but a suitable CMS becomes part of the proposal. WordPress deserves a fresh comparison because its editor may meet that requirement with less integration work. Change another requirement: the business already relies on a WordPress plugin to coordinate bookings and payments. Keeping WordPress may now be the lower-risk choice. Rebuilding a working operational system just to change the frontend is a much larger decision than replacing a brochure site. Use this exercise in discovery. Change the requirements and see whether the recommendation changes. If the answer is always the developer's favorite framework, the evaluation is not doing its job. Decide whether a migration is worth doing A working WordPress site does not need replacement because Astro exists. First identify the problem: slow pages, an unusable editor, excessive maintenance, or a design that no longer fits the business. Some problems can be fixed without changing platforms. If a migration is justified, make an inventory of existing URLs, content, images, metadata, forms, and integrations. Preserve useful URLs where possible. Map changed URLs to relevant destinations instead of sending everything to the homepage, and check internal links after the move. Avoid these common shortcuts: Comparing a minimal Astro demo with an unoptimized production WordPress site. Calling static delivery maintenance-free. Assuming every editor needs a CMS, or assuming nobody does. Replacing a working booking or checkout workflow without testing its replacement. Promising better rankings simply because the framework changes. Before signing off, request a demonstration of editing, publishing, and recovery, plus a written handover plan. Choose Astro for a content-focused site with an agreed editing workflow and capable technical ownership. Choose WordPress when its editor or established integrations solve the business's needs more directly. Keep the current site when the migration cannot justify its disruption. Frequently asked questions Is Astro better than WordPress for a small business? Astro is a strong option for a content-focused site with an agreed editing workflow and technical support. WordPress is often the more direct choice when staff need its built-in editor or established plugins. Choose the complete setup, not the framework in isolation. Can a nontechnical owner update an Astro website? Yes, if the project includes an appropriate CMS or editing interface. Astro alone does not provide a WordPress-style dashboard. Without an editor, content changes usually go through someone comfortable with the project's files and publishing workflow. Does switching to Astro improve SEO automatically? No. Astro can support a lightweight implementation, but rankings also depend on content relevance and other signals. A migration must preserve useful URLs, internal links, metadata, and indexability. Good performance scores do not guarantee higher rankings. Can Astro use WordPress as its CMS? Yes. Astro can retrieve content through the WordPress REST API while WordPress remains the editing system. The project still needs WordPress maintenance, frontend deployment, and a tested approach to previews and publishing. Image concepts Image production is outside this demonstration's scope. These are concepts, not existing assets. No placeholder image tags have been inserted. The inline concepts are optional editorial suggestions, not instructions to override the site's image policy. Featured image: two publishing workflows Role: Explanatory editorial illustration. Placement: After the opening paragraph. Suggested filename: astro-vs-wordpress-publishing-workflows.webp Alt text: “A browser editor and a file-based publishing workflow both leading to a finished business website.” Prompt: Create a wide 16:9 editorial 3D illustration showing two equally credible publishing routes. On the left, a browser editing panel with content blocks; on the right, document files passing through a build stage. Both connect to the same finished small-business website. Use a warm beige #E9E6DF background, substantial charcoal forms, paper-colored panels, and several lime accents. Crisp edges, restrained glass details, clear directional connections, studio lighting. Avoid winner trophies, speed gauges, logos, fabricated screenshots, tiny text, people at laptops, and decorative clutter. Inline concept: the editing acceptance test Role: Workflow diagram. Placement: “Test editing before choosing the stack.” Suggested filename: website-editor-acceptance-test.webp Alt text: “Editing test showing an opening-hours change, photo replacement, preview, and publication.” Prompt: Design a readable 4:3 workflow diagram with four connected stages: edit opening hours, replace a photo, preview the page, publish the update. Show recognizable content panels rather than brand-specific interfaces. Use beige #E9E6DF, charcoal, paper, and lime. Give every stage generous space. Add labels during design production for accurate typography. Avoid fake software screenshots, approval badges, decorative people, and implied measured results. Inline concept: what visitors receive Role: Architecture comparison. Placement: “Compare finished pages, not framework promises.” Suggested filename: astro-wordpress-page-delivery.webp Alt text: “Static Astro delivery beside WordPress delivery with separate cache-hit and cache-miss paths.” Prompt: Create a wide technical diagram with two horizontal lanes. Astro: content and templates, build, static files, visitor. WordPress: visitor request, page cache, cached response; show a separate cache-miss branch to application and database before returning HTML. Add a small annotation area for Astro's optional on-demand rendering. Use matching visual weight for both lanes, beige background, charcoal connectors, and lime route highlights. Avoid latency numbers, winner labels, or implying every WordPress visit queries a database. Inline concept: maintenance ownership Role: Responsibility diagram. Placement: “Account for maintenance on both sides.” Suggested filename: website-maintenance-responsibilities.webp Alt text: “Shared website responsibilities alongside WordPress application maintenance and Astro build maintenance.” Prompt: Create a 4:3 responsibility diagram. Put shared tasks in a central column: domain, accounts, hosting, integrations, recovery. Place WordPress core, themes, plugins, and database on one side; Astro dependencies, build workflow, and optional runtime or CMS on the other. Use paper cards over warm beige, charcoal typography, and lime grouping markers. Keep the mood practical and neutral. Avoid shields suggesting immunity, empty Astro maintenance columns, numerical risk scores, and logos. Structured data The following draft JSON-LD parses successfully, and all four FAQ questions and answers match the article. Publication-specific fields are deliberately absent: image, url, mainEntityOfPage, author identity, and publication dates must come from the approved publication and real assets. This is a draft schema, not a claim that a page or image has been published. FAQPage remains a Schema.org type, but Google's documentation changelog states that FAQ rich results are no longer shown. This markup is not a promise of search-result enhancements. { "@context": "https://schema.org", "@graph": [ { "@type": "BlogPosting", "headline": "Astro vs WordPress: choose for the person editing", "description": "Astro vs WordPress for small business websites: compare editing, speed, maintenance, and integrations. Use a practical checklist to choose your setup.", "inLanguage": "en-US", "about": [ { "@type": "Thing", "name": "Astro" }, { "@type": "Thing", "name": "WordPress" } ] }, { "@type": "FAQPage", "inLanguage": "en-US", "mainEntity": [ { "@type": "Question", "name": "Is Astro better than WordPress for a small business?", "acceptedAnswer": { "@type": "Answer", "text": "Astro is a strong option for a content-focused site with an agreed editing workflow and technical support. WordPress is often the more direct choice when staff need its built-in editor or established plugins. Choose the complete setup, not the framework in isolation." } }, { "@type": "Question", "name": "Can a nontechnical owner update an Astro website?", "acceptedAnswer": { "@type": "Answer", "text": "Yes, if the project includes an appropriate CMS or editing interface. Astro alone does not provide a WordPress-style dashboard. Without an editor, content changes usually go through someone comfortable with the project's files and publishing workflow." } }, { "@type": "Question", "name": "Does switching to Astro improve SEO automatically?", "acceptedAnswer": { "@type": "Answer", "text": "No. Astro can support a lightweight implementation, but rankings also depend on content relevance and other signals. A migration must preserve useful URLs, internal links, metadata, and indexability. Good performance scores do not guarantee higher rankings." } }, { "@type": "Question", "name": "Can Astro use WordPress as its CMS?", "acceptedAnswer": { "@type": "Answer", "text": "Yes. Astro can retrieve content through the WordPress REST API while WordPress remains the editing system. The project still needs WordPress maintenance, frontend deployment, and a tested approach to previews and publishing." } } ] } ] } Internal linking plan This article links to Destination Anchor used Purpose Website without a CMS website without a CMS Show the site's documented file-based content workflow. WordPress maintenance WordPress maintenance Keep detailed maintenance coverage on its existing page. What is a headless CMS? how a headless CMS works Explain the architecture without expanding this comparison into a separate CMS tutorial. The headless anchor follows a recorded query variation. The maintenance anchor is a natural topic description; no ranking claim is made for that exact phrasing. The newer no-CMS article has no demonstrated cluster in the inspected snapshot. Suggested links to this article These are recommendations only; no links were added. From the no-CMS article, beside the discussion of nontechnical editors: “Astro vs WordPress for a small business.” From the WordPress maintenance article, when discussing rebuilding versus maintaining: “when switching from WordPress makes sense.” From the Astro-versus-Next.js article, beside the conventional-CMS alternative: “compare Astro with WordPress.” Publishing checklist Completed for this demonstration [x] Full article delivered in US English. [x] Article exceeds 1,000 words. [x] Hook-driven title and metadata lengths checked. [x] Existing coverage and verified keyword clusters inspected. [x] Official sources consulted for technical claims. [x] Hypothetical scenario clearly distinguished from client evidence. [x] Table of contents mirrors the article's H2 sections. [x] Four visible FAQ answers supplied. [x] Draft JSON-LD parsed and FAQ text parity verified. [x] Final language pass removed promotional claims and unsupported certainty. [x] Website, Git, GitHub, authentication, and third-party content left unchanged. Required only if publication is later approved [ ] Confirm the route and recheck overlapping coverage. [ ] Obtain editorial approval and confirm the author byline. [ ] Set actual publication and modification dates. [ ] Produce the approved featured image; set alt text and Open Graph metadata. [ ] Decide whether any optional inline diagrams fit the site's editorial policy. [ ] Verify asset format, dimensions, and file size. [ ] Populate structured-data image and publication fields with verified values. [ ] Integrate with existing schema output without duplicate article or FAQ nodes. [ ] Configure the appropriate canonical URL for the publication destination. [ ] Add approved contextual links in both directions. [ ] Verify rendered links, heading anchors, mobile tables, and desktop/mobile layout. [ ] If published, assess Search Console results after at least 30 days. This is the complete demonstration draft and writing package. Nothing has been published. Show more 2 of 2 messages This is writing output to review, not an approved article. A short follow-up narrows the same draft to developers maintaining the site: Hermes Agent: focus the outline on developers gpt-6-astra You Focus on developers maintaining the site. Show me the outline first. Agent Proposed title Astro vs WordPress: what developers maintain after launch Audience Developers responsible for small business websites after handover: content changes, dependency updates, forms, production failures, and eventual migration. Angle Compare the work each setup leaves you with. Keep the earlier draft's distinctions around caching, headless WordPress, and editing, but move the focus from the owner's platform choice to the maintainer's responsibilities. Outline Choose the maintenance model before the framework Open with the recommendation: - Static Astro is a strong fit when the site mostly publishes content and its publishing workflow has a clear technical owner. - Conventional WordPress is often more practical when its editor and established plugins already meet the business's needs. - Keeping a working site is a valid outcome. Define the comparison: static-first Astro versus conventional WordPress with sensible caching and maintenance. Cover on-demand Astro and headless WordPress as separate configurations. What changes when the public site becomes static? Explain the request path briefly, then connect it to operational work: - Prebuilt Astro pages versus cached and uncached WordPress responses. - What removing a public PHP application and database removes from maintenance. - What remains: dependencies, deployment access, hosting, domains, and integrations. - How adding SSR changes the responsibilities again. Include one compact comparison table organized by maintenance task, not feature scores. Follow a content change from request to production Trace the same change through both setups: update a service description and replace its image. Cover: - WordPress editing, preview, publication, and cache invalidation. - Astro file changes or CMS updates, validation, build, and deployment. - Diagnosing “published in the editor, missing on the website.” - Who handles urgent corrections when the usual maintainer is unavailable. Treat the editor as part of the system the developer supports, not a separate convenience. Updates and recovery: what happens when something breaks? Use two clearly labeled hypothetical incidents: - A WordPress plugin update breaks the contact form. - An Astro dependency update prevents deployment. Explain: - Staging, backups, dependency locks, and focused regression checks. - The difference between a failed build and a broken live deployment. - Why a code rollback does not necessarily reverse database changes. - What a recovery procedure must cover beyond “revert the commit.” Takeaway: define and test recovery for the actual deployment setup. Forms and bookings often determine the workload Follow the business-critical path beyond the frontend: - Form submission, validation, spam protection, and delivery. - Embedded scheduling tools versus booking plugins or custom integrations. - Payments, webhooks, and external service failures where relevant. - Checks that prove an inquiry reached its destination. Show when replacing a working plugin creates more maintenance than it removes. Headless WordPress: keep the editor, accept another system Explain when Astro plus WordPress is justified. Cover the additional work: - API access and private previews. - Build triggers, publication delays, and failed updates. - Rendering blocks and features that previously depended on the theme. - Maintaining both WordPress and the Astro frontend. Keep this section short: an operational trade-off, not an integration tutorial. Make the decision against the site you actually maintain Apply the comparison to a hypothetical small service-business site. Change its requirements to show when the recommendation changes. End with a practical checklist: - Who edits, and how urgently? - Which integrations already work? - Who owns updates and recovery? - What can another developer take over? - Could the current site's problems be fixed without migrating? Include performance checks here: representative pages, real scripts and embeds, consistent test conditions, and no automatic SEO benefit. Frequently asked questions Does a static Astro site still need dependency updates? Can a failed Astro build take the live website down? Does managed WordPress hosting remove the developer's maintenance work? When does headless WordPress justify maintaining two systems? Essential editorial decisions Use developer-to-developer language. Explain business consequences without turning the article into a sales pitch. Keep the public Straffe Sites content-in-Git example, but use it only as architecture evidence, not proof that Astro wins universally. Replace the earlier owner's editing test with publishing, failure diagnosis, and recovery workflows. Avoid fabricated maintenance hours, cost savings, benchmarks, or first-person incident stories. Keep detailed migration instructions and framework setup code out of scope. End with a maintenance decision checklist rather than a contact CTA. Visual concepts only: a publishing-flow diagram and a recovery-path comparison. No images or article implementation at this stage. Show more 2 of 2 messages An outline lets you check the angle before another writing pass. Give Hermes your own code, notes, or test results when you want first-hand examples; the agent cannot invent your experience. Audit an existing page The URL is enough to request a page audit. Hermes loads the audit skill, examines the page, and identifies improvements. If its GSC connection has access to that property, it can use the search data too; otherwise it should explain that limitation. Hermes Agent: SEO audit (compatible trace import) gpt-6-astra You /notfair-seo-page https://straffesites.com/en Agent Page SEO Analysis — https://straffesites.com/en September 13, 2026 · GSC data: June 13–September 10, 2026 · 90 days, final data The page is indexed, its canonical is correct, and its technical foundation is strong. The main opportunity is clearer, better-qualified commercial messaging—not an indexability repair. The audited URL is the English business homepage, not a developer tutorial. It should help prospective clients understand the service, assess the evidence, and contact the team. Tutorial content is supporting material. Overall Score: 7.8/10 These are editorial assessments, not Google scores, PageSpeed measurements, or ranking predictions. GSC metrics and browser observations are identified separately. Dimension Score Weight Weighted Search Intent Alignment 8.0/10 20% 1.600 E-E-A-T Signals 7.5/10 20% 1.500 Content Quality & Depth 7.0/10 20% 1.400 On-Page SEO 8.5/10 15% 1.275 Content Structure & UX 8.0/10 15% 1.200 Technical SEO 8.5/10 10% 0.850 Overall 7.825 → 7.8 Why these scores Dimension What earns the score What prevents a higher score Search intent Services, portfolio, process, and “Discuss your project” fit a commercial homepage. The headline emphasizes speed without immediately identifying the small-business audience. Actual GSC queries are sparse and ambiguous. E-E-A-T Named contact, 12 linked case studies, linked Google reviews, technical explanations, and an HTTP Archive citation. Hero performance claims lack an adjacent measurement date, sample definition, and clearly named loading metric. Content quality Covers services, examples, process, editing, support, and terminology. Buyers get limited detail about project scope and delivery dependencies. A substantial part of the content is article-card text rather than buyer guidance. On-page SEO Complete metadata, one H1, descriptive links, responsive WebP images, and language annotations. Minor English-copy issues and an opportunity to make the title more audience-specific. Structure and UX Short sections, a clear primary CTA, native FAQ disclosures, and no horizontal overflow in the tested viewports. The article rail contains 34 cards, which may be more choice than a homepage visitor needs. No conversion or usability study was available. Technical SEO Google confirms indexing; server-rendered content, self-canonical, valid JSON-LD parsing, HTTPS, and responsive geometry. No fresh Lighthouse or URL-level field-performance assessment was run, and this was not a full accessibility or asset audit. Top Priority Fixes No critical indexability blocker was found. The biggest improvement would be making the existing performance evidence precise and easy to verify. Strong numbers are useful only when visitors understand what was measured. #1 — Qualify the hero’s performance claims 🟡 High Score impact: Potentially +0.5 in E-E-A-T and +0.5 in Content Quality. These are editorial estimates, not projected ranking gains. Current: “Our case sites reach a 98/100 median mobile PageSpeed score; the fastest loads in 0.9 seconds.” Fix: Add a nearby evidence link and state: The measurement period. The number of measured case sites. How the median was calculated. Which metric the 0.9-second figure represents. Whether the measurement is from a lab test or real-user data. Do not describe LCP as total page-load time if LCP is the underlying metric. A safe nonnumeric alternative, pending verification of those details: “Explore our case studies for monthly PageSpeed measurements and Search Console reporting.” Why: The audit verified that the numbers appear on the page; it did not independently reproduce them. Clear provenance strengthens trust and avoids confusing a lab performance score with a visitor-experience guarantee. #2 — Update the “latest” HTTP Archive comparison 🟡 High Score impact: Potentially +0.5 in Content Quality and +0.5 in the Trustworthiness subscore. Current heading: “We build with Astro — the Core Web Vitals leader in the latest HTTP Archive comparison” Current explanation: “In July 2026, 69% of measured mobile Astro sites had good Core Web Vitals, compared with 49% for WordPress and 33% for Next.js.” Verified finding: The linked source confirms those July values. However, it now displays August 2026 as the latest period, with Astro at 71%, WordPress at 48%, and Next.js at 35%. Fix: Suggested heading: “Astro leads this Core Web Vitals comparison” Suggested explanation: “In HTTP Archive’s August 2026 mobile comparison, 71% of measured Astro origins had good Core Web Vitals, compared with 48% for WordPress and 35% for Next.js.” Keep the source link. Explain that an origin groups pages under the same protocol, host, and port; this is not a measurement of every page built with a framework. Why: The existing July figures are not fabricated or disproved, but “latest” is stale. Framework-level comparisons also do not prove that a particular website will pass Core Web Vitals. #3 — Make the audience more explicit in the search snippet 🟢 Medium Score impact: Potentially +0.5 in Search Intent Alignment and +0.3 in On-Page SEO. Current title: “Straffe Sites — rock-solid websites that load fast” Current H1: “A rock-solid site that loads fast” Fix: Test this title rather than assuming the existing one is underperforming: “Fast websites for small businesses | Straffe Sites” The proposed title is 50 characters. Keep the distinctive H1 if desired, but make the first sentence more explicit: “We design and build fast websites and online stores for independent professionals and small businesses. Seppe is your main contact, supported by a senior team.” Why: The current meta description already identifies the audience. Bringing that clarity into the title or opening sentence helps qualified visitors recognize the fit. GSC does not show a proven CTR problem here. This is a relevance hypothesis, not a fix justified by a statistically reliable CTR deficit. #4 — Give buyers more useful project-planning answers 🟢 Medium Score impact: Potentially +0.5 in Content Quality. Current timeline answer: “It varies by project. Because you work directly with the developer, communication is quick. After our first conversation, you’ll get a realistic schedule.” Fix: Explain the factors that determine the schedule without inventing a delivery promise: “The schedule depends on the number of pages, content readiness, custom integrations, and feedback rounds. After the first conversation, we outline the project milestones and what we need from you.” Review the content-editing answer in the same way: distinguish projects with an editor-friendly CMS from projects where content is maintained through a development workflow. Why: Competitors explain publishing autonomy, migrations, and ongoing delivery in more detail. A few concrete answers would help buyers qualify their project without turning the homepage into a technical manual. E-E-A-T Breakdown Signal Score Evidence Experience 8/10 Twelve named case-study cards and practical delivery language: “You speak directly with the builder” and “You see the progress as it happens.” The homepage does not itself show detailed before-and-after evidence. Expertise 8/10 Correctly identifies LCP, INP, and CLS in the glossary; explains integrations, maintenance, CMS editing, and a staged delivery process. The hero’s “loads in 0.9 seconds” wording lacks metric precision. Authoritativeness 7/10 Seppe is named, the team page is linked, the server-rendered content states “25+ years of experience,” and relevant case studies and technical articles are linked. Independent reputation and backlinks were not assessed. Trustworthiness 7/10 HTTPS, direct contact details, legal links, a Google-review link, and an HTTP Archive citation. The review rating and case-performance aggregate were not independently remeasured; the “latest” comparison needs updating. YMYL: This is not primarily a health, financial-advice, legal-advice, or safety page. Health-related client names in the portfolio do not make the homepage a medical-advice resource. E-E-A-T Gaps to Close Attach measurement context directly to the hero’s numerical claims. Keep dated comparisons synchronized with their sources, or remove “latest.” Consider one short, permission-cleared client quotation with attribution and a relevant case link. Do not invent a testimonial. Make ownership, handover, and editing responsibilities clearer where the actual service agreement supports those claims. The page displays “4.9/5 on Google” and “26 reviews.” These are observed page claims, not independently verified review metrics from this audit. Search Intent Analysis Target keyword: “Fast websites for small businesses” is an inferred commercial theme, not an established high-volume query for this URL. Actual leading disclosed GSC query: “fast sites,” with 3 clicks and 17 impressions. Intent type: Commercial service selection and branded navigation. Content format match: Yes for the commercial theme; uncertain for the ambiguous query “fast sites.” Search-result reality check Two searches were used to avoid judging intent from the homepage alone. Search Observed result sample Interpretation fast website development small business Astro agency Astro Partner Agencies; Astro’s framework homepage; Lucky Media; Seibert; Opace A mixture of agency discovery, commercial service pages, and framework information. The homepage’s service format is compatible. fast sites Louisiana’s FastSites program; a governor’s announcement; WAFB coverage; a Catchpoint performance article; Louisiana Illuminator coverage Strong ambiguity. This is not a clean web-development purchase query in the returned sample. These are current search-tool results, not a controlled Google rank-tracking study. Geography, device, and personalization were not matched to the historical GSC impressions. Conclusion: Do not optimize the homepage around “fast sites” simply because it produced three clicks. Preserve the homepage’s brand and service role, and let dedicated service pages own narrower purchase queries. SERP Feature Opportunities Feature Optimized? Fix Featured snippet Not established No featured-snippet ownership was confirmed. Do not add a long informational section solely to chase one. People Also Ask Structurally prepared Four visible FAQs provide question-and-answer content, but PAA appearances were not reported by the search tool. Improve buyer usefulness rather than promising placement. Rich results Markup present; appearance unconfirmed Organization, WebSite, and FAQPage JSON-LD parse successfully. URL Inspection did not return a rich-result assessment. Markup does not guarantee an enhanced result. Image results Basic preparation present Descriptive alt text and WebP assets exist. Image-search visibility was not measured. On-Page SEO Audit Metadata Element Current Status Recommendation Title tag “Straffe Sites — rock-solid websites that load fast” — 50 characters Good length and clear benefit Consider the audience-specific variant above. No demonstrated truncation problem. Meta description “The Straffe Sites team designs and builds fast websites and online stores for independent professionals and small businesses, with no agency in between.” — 152 characters Complete and relevant Retain the audience clarity. A stronger invitation to view work is optional, not essential. H1 “A rock-solid site that loads fast” One H1; clear benefit Clarify the service and audience in the adjacent introduction. Canonical https://straffesites.com/en Correct Google-selected and user-declared canonicals agree. Robots metadata No robots meta tag; no X-Robots-Tag in the checked response No exclusion detected An explicit index,follow tag is unnecessary. Open Graph Title, description, URL, image, type, site name, and en_US locale Complete The declared 1200×630 image URL returned HTTP 200; visual preview not reviewed. Twitter Card summary_large_image, title, description, and image Complete No urgent change. Language HTML lang="en" Appropriate Continue using US English consistently. Hreflang nl, en, and x-default Present on the audited page Reciprocal annotations on the Dutch page were outside this page-only audit. Sitewide title and description uniqueness was not tested. Heading Structure The main content has one H1 and a consistent H2 → H3 hierarchy. H1: A rock-solid site that loads fast H2: We build with Astro — the Core Web Vitals leader in the latest HTTP Archive comparison H2: One team, everything for your site H3: Web development H3: Custom features & integrations H3: Website maintenance H3: Technical partner H3: AI design to website H2: Work with real personality H3: Verhuurwinkel.nl H3: Straffe Sites H3: Voltti.ai H3: Gitaarlessen Boeckx H3: 2140 Boxing Training H3: Figur H3: New Impact H3: Roulez Roulez H3: sympl H3: ZET H3: HWV Facilities H3: CLW Antwerpen H2: How we work together H3: Introduction H3: Design H3: Build H3: Launch & support H2: No agency. Just a senior team H2: Keep reading H3: 34 linked article titles H2: Frequently asked questions H2: Terms H3: CMS H3: Responsive web design H3: Core Web Vitals H3: SEO H3: Web hosting H3: Website maintenance H2: Ready for a rock-solid site? The article-card H3s cover CMS integrations, websites without a CMS, agency SEO research, lab versus field performance, website costs, semantic markup, AI writing, Search Console, Storyblok, Astro, hiring developers, maintenance, keyword research, and implementation tutorials. Navigation and contact-interface headings also exist outside <main>. They are not extra page H1s. Assessment: Logical structure. The main weakness is not heading hierarchy but emphasis: the long framework-comparison heading is more technical than the buyer-oriented service headings. Internal Links Found 122 same-origin link elements across the document, including navigation, repeated destinations, and fragment links. 63 are inside <main>. These are link-element counts, not counts of unique destination pages. Anchor text or card heading Target Quality Discuss your project /en/contact Clear conversion action See recent work ↓ /en#werk Useful on-page navigation; target exists Web development /en/website-development Relevant; card description adds context Custom features & integrations /en/web-development Descriptive and differentiated Website maintenance /en/website-maintenance Strong service anchor AI design to website /en/ai-design-to-website Specific service intent Meet the team ↗ /en/team Useful trust destination Straffe Sites case card /en/case/straffe-sites Useful supporting evidence Core Web Vitals /en/glossary/core-web-vitals Relevant explanation View all articles /en/blog Appropriate directory action The checked contact, service, team, and own-case destinations returned HTTP 200 without a redirect. This was a targeted check, not a full crawl of every link. The large link count is not automatically an SEO defect. Much of it comes from the portfolio, article rail, and navigation. A shorter article selection could improve decision-making, but there is no measured evidence here that link count is harming rankings. External Links Two outbound HTTPS link elements were found: Link Purpose Assessment Google reviews Reputation evidence Useful direct source; rating and count not independently confirmed HTTP Archive comparison Framework-performance citation Source inspected successfully in a browser; July values confirmed and newer August values found Email and telephone links are contact actions, not external web citations. Images Found 49 <img> elements: Image group Count Format and attributes Assessment Case-study images 12 WebP, width/height attributes, responsive candidates, lazy loading Strong implementation Article-card images 34 WebP, 800×450 declared dimensions, lazy loading Mostly responsive candidates; four have only an 800w candidate Reused Seppe portraits 3 WebP with responsive candidates Two lazy-loaded; the review avatar uses normal browser loading All images have an alt attribute and declared width and height. 48 are lazy-loaded. One review-avatar image has empty alt text; that can be appropriate because the surrounding review link already has an accessible label. Representative findings: Image Current alt text Issue or recommendation Verhuurwinkel case “Players in transparent bubble suits running at each other during a game of bubble football” Descriptive and relevant Straffe Sites case “…against a light grey background” Use “gray” for consistent US English Figur case “…with grey curly hair…” Use “gray” New Impact case “Camera operator filming a effects technician…” Correct to “an effects technician” CMS article illustration “Abstract Straffe Sites illustration of AI agents connecting to a CMS through MCP” Understandable; avoid adding keywords merely for SEO Four article assets with only an 800w candidate were observed at encoded sizes of 7,288, 17,778, 7,446, and 18,088 bytes. Smaller variants might save bytes, but these are not evidence of a major performance problem. Content Quality Assessment Helpful Content Signals Signal Present? Evidence Clear target audience Partial The meta description names independent professionals and small businesses; the hero is broader. Answers the query completely Mostly Services, portfolio, process, content editing, maintenance, and contact are covered. Project-planning detail is limited. Original value added Yes Named projects, a direct-contact model, and linked measurement-oriented case studies. Passes the “Last Click” test Partial Enough to begin a conversation; less useful for comparing scope, handover, and ongoing responsibilities. Appropriate depth Yes, with a composition caveat 1,167 words in the extracted main-content text, including FAQs, glossary cards, and article-card text. First-hand knowledge Yes Practical delivery descriptions and a substantial linked portfolio. Human-first presentation Mostly Direct language and clear CTAs; the long article rail serves several audiences at once. Word-count method: Text nodes were joined with spaces; scripts, styles, navigation, and aside elements were excluded. The same method was used for the competitor comparisons. Counts describe content volume, not quality or words visible simultaneously on screen. No page-level publication or update date was found in <time> elements or the JSON-LD. A homepage does not require an article-style date, but numerical claims should carry their own date. Content Gaps vs Competitors Two commercial pages from the exploratory search were fetched and inspected. They are comparison references, not proof that Straffe Sites competes against them for every query. Competitor Page type Measured main-content words Relevant strengths Lucky Media Detailed Astro agency service page 4,327 Named client quotations, migration examples, publishing autonomy, ownership, retainer support Seibert Astro agency landing page 1,584 Development, migration, performance optimization, integrations, consulting, and maintenance explanations Straffe Sites /en General commercial homepage 1,167 Broad portfolio, small-team model, direct contact, concise service overview Lucky Media H2 topics: platform limitations; delivered Astro projects; customer pain points; reasons to choose the agency; promise; process; services; enterprise projects; ongoing support; features; FAQs. Seibert H2 topics: business impact of performance; publishing workflows; Astro performance; islands; performance demonstration; services; FAQs; UI kit; company scale; partnership; contact. Topic/subtopic This page Competitor evidence Action Who the service is for Explicit in metadata; broad in hero Both identify more specific buyer scenarios Make the opening audience clearer Content-editing autonomy One brief FAQ answer Both explain publishing workflows in more depth Clarify available editing approaches Migration concerns Not explained in the main service overview Both describe migration work Add a short answer or link if this is part of the intended offer Ownership and handover Not clearly stated in the homepage copy Lucky Media explicitly discusses ownership and lock-in State only verified contractual terms Attributed customer testimony Aggregate Google-review badge Lucky Media displays named quotes and roles Consider one approved, relevant quote Ongoing support Present but brief Both describe support more specifically Explain responsibilities and next steps without publishing prices Do not copy competitors’ absolute promises about rankings, “instant” loading, or guaranteed performance. More aggressive wording is not better evidence. Technical SEO Check Status Details HTTP response Pass Audited URL returned HTTP 200 Indexability Indexed URL Inspection: PASS, “Submitted and indexed” Robots.txt Pass HTTP 200; User-agent: * and Allow: / Indexing directives Pass Google reports INDEXING_ALLOWED; no checked meta/header exclusion Canonical Pass User-declared and Google-selected canonical both equal https://straffesites.com/en Last Google crawl Confirmed September 5, 2026, 19:09:45 UTC; successful fetch; crawled as mobile Server-rendered content Pass Full main content available in fetched HTML, not an empty JavaScript shell Mobile readiness Positive bounded evidence No horizontal document overflow at 390px; viewport metadata present Desktop layout Positive bounded evidence No horizontal document overflow at 1440px H1 wrapping Pass in tested layouts Two measured line bands at both 1440px and 390px Primary CTA Adequate measured size Approximately 240×53px on desktop and 350×53px on mobile Intro text Readable measured size 20.8px desktop; 18px mobile FAQ container Contained on mobile Heading begins 20px from the left and remains inside the viewport Schema markup Basic checks pass Organization, WebSite, and FAQPage JSON-LD parse; all four FAQ answers match the page text Rich-result status Unconfirmed Inspection returned no rich-result assessment Google mobile-usability verdict Unspecified VERDICT_UNSPECIFIED; this is not a mobile-usability pass Page-speed signals Favorable proxies only No external stylesheet links; one inline head style block; module scripts and asynchronous analytics Fonts Positive Local WOFF2 fonts, two font preloads, and font-display: swap declarations DOM size Observed, not diagnosed 968 elements in the inspected document HTTPS/mixed content Pass in checked markup HTTPS; no HTTP URLs found in inspected src/href attributes Core Web Vitals Not measured for this URL No fresh field-data or Lighthouse verdict established Browser geometry is not a substitute for visual review, assistive-technology testing, or real-user monitoring. No accessibility certification or full performance pass is claimed. The page’s 98/100 case aggregate and the HTTP Archive framework percentages are not measurements of this homepage’s current Core Web Vitals. GSC Performance Summary Property: sc-domain:straffesites.com Exact page: https://straffesites.com/en Period: June 13–September 10, 2026 Data state: Final Page totals were taken from page-dimension data, not reconstructed from disclosed query rows. Metric Value Clicks, 90 days 7 Impressions, 90 days 105 Average CTR 6.67% Average position 5.66 Trend Too little data for a reliable growth or decline conclusion Average position is a historical GSC aggregate—not the page’s current fixed rank. Top Ranking Queries All five disclosed query rows for this page are shown below. Query Avg. position Clicks Impressions CTR Expected CTR Gap fast sites 6.00 3 17 17.65% 3–4%, only if treated as transactional +13.65 to +14.65 percentage points; intent uncertain fast site 8.00 0 2 0% 1.5–3%, only if treated as transactional −3 to −1.5 percentage points; sample too small sites f 7.75 0 4 0% N/A Unclear intent; no suitable benchmark straffe 6.13 0 8 0% N/A Could be brand-related or unrelated; insufficient evidence websites starting with s 27.00 0 1 0% N/A Outside the supplied benchmark range; poor commercial fit The benchmark ranges are generic reference bands, not measured expectations for these exact searches. No SERP-feature discount was applied because no relevant feature was confirmed. Query-data limitation: Disclosed queries account for 3 of 7 clicks and 32 of 105 impressions: 42.86% and 30.48%, respectively. They are not the complete search-query picture. There is no defensible basis for predicting additional clicks from a title change with this sample. Trend Across Three Nonoverlapping 30-Day Periods Period Clicks Impressions CTR Avg. position June 13–July 12 2 26 7.69% 4.50 July 13–August 11 1 45 2.22% 6.04 August 12–September 10 4 34 11.76% 6.03 The latest period has more clicks but fewer impressions than the preceding period. With single-digit clicks, describing this as sustained growth would overstate the evidence. No algorithm-update attribution is justified. Cannibalization Check The disclosed query fast sites appeared for: Page Clicks Impressions Avg. position /en 3 17 6.00 / 0 15 3.47 /blog/laadtijd-website 0 1 5.00 This is query overlap, not proven harmful cannibalization. The Dutch homepage had the stronger average position, while the English homepage received the disclosed clicks. Language and geography could explain part of that difference. Do not consolidate the language homepages or change canonicals on this evidence. Maintain distinct language roles and monitor relevant query/page combinations over a longer period. What to Improve Next Correct small English-copy issues. Change “a effects technician” to “an effects technician” and standardize “grey” to “gray” in the observed alt text. Evaluate the article rail as a commercial UX choice. It contains 34 cards. Consider whether a smaller curated selection would help buyers, while keeping the full blog directory available. This is a usability hypothesis, not a proven ranking fix. Preserve the distinction between website builds and custom development. The links to /en/website-development and /en/web-development serve different roles. Keep their labels differentiated rather than targeting every service page with the same phrase. Run a dedicated performance check before changing loading behavior. Current HTML and resource signals are favorable, but they do not establish LCP, INP, or CLS. Reassess after at least 30 days following any future change. Keep a dated baseline, compare matching periods, and focus on qualified commercial queries. Low traffic may require a longer observation window. Skill Handoffs No follow-up workflow was executed. Handoff Purpose Metadata optimization Develop audience-specific title and description alternatives without assuming the current CTR is deficient Content writing Refine the hero’s evidence wording and expand buyer FAQs using verified service details Keyword research Validate relevant English commercial demand instead of treating “fast sites” as a reliable primary keyword Structured-data review Check search-feature eligibility separately from JSON syntax; no missing-schema emergency was found Search Console follow-up Reassess this exact URL after at least 30 days, with query/page overlap and low-volume limitations preserved Bottom line: This is an indexed, technically sound commercial homepage with useful portfolio depth. The strongest next step is to make its evidence more precise and its buyer guidance more specific—not to add keywords indiscriminately, expand it into a tutorial, or chase an ambiguous query. Show more 2 of 2 messages Its scores and recommendations are the agent's assessment, not a Google rating or a promise of results. You can narrow the audit to three priorities without letting it edit the page: Hermes Agent: choose three audit priorities gpt-6-astra You Which three changes would you prioritize? Don't edit the page yet. Agent I’d prioritize these three changes to https://straffesites.com/en, in this order, based on the recorded audit. Make the hero’s performance claims verifiable The line “98/100 median mobile PageSpeed score; the fastest loads in 0.9 seconds” needs context. Add a short measurement note and an evidence link stating the period, number of case sites, and calculation method. Identify exactly what the 0.9 seconds measures. If it is lab LCP, call it that rather than total loading time. Until those details are verified, use: “Explore our case studies for monthly PageSpeed measurements and Search Console reporting.” Why first: Performance is the page’s central selling point. Visitors should be able to check the evidence without guessing what the numbers mean. The audit confirmed the claims were present, not that the aggregate was independently reproduced. Correct the dated HTTP Archive comparison The heading says “latest,” but the paragraph uses July 2026 figures. The audit confirmed those July figures and found August data in the linked source. Suggested heading: “Astro leads this Core Web Vitals comparison” Suggested paragraph: “In HTTP Archive’s August 2026 mobile comparison, 71% of measured Astro origins had good Core Web Vitals, compared with 48% for WordPress and 35% for Next.js.” Keep the source link and briefly explain that these are framework-level results across measured origins, not a guarantee for an individual website. Avoid “latest” unless the wording is maintained with every update. Why second: This is a specific, verified freshness issue in a prominent evidence block. Correcting it is more defensible than changing copy based on speculative keyword gains. Make the service and audience explicit at the top Keep “A rock-solid site that loads fast” as the H1. It already fits the tested desktop and mobile layouts. Clarify the audience in the opening sentence instead. Suggested introduction: “We design and build fast websites and online stores for independent professionals and small businesses. Seppe is your main contact, supported by a senior team.” Suggested title: “Fast websites for small businesses | Straffe Sites” Put the qualified measurement note from priority one beside or below this introduction. Why third: Prospective clients should immediately recognize what you build and whether it is for them. The existing meta description already does this better than the hero. I would not target “fast sites” aggressively: the recorded search results were ambiguous, and the page’s GSC sample was too small to establish a CTR problem. These are editorial priorities, not Google ratings or promises of better rankings. I’d leave the indexed URL, canonical, schema, and broader layout alone for now. No page edits or new audit were performed for this follow-up. Show more 2 of 2 messages Find a topic using Search Console Use the planner when you haven't chosen a subject. Ask it to check whether an existing page already answers the question before proposing another article. Then take the topic you prefer to the writing skill. Hermes Agent: choose three topics from Search Console gpt-6-astra You /notfair-content-planner https://straffesites.com Suggest three article topics using my Search Console data. Agent I recommend three article refreshes rather than three new posts. Each topic already has a relevant page earning impressions; a new URL would split the same search intent. Search Console connection verified: sc-domain:straffesites.com Period: June 13–September 10, 2026, inclusive, finalized Web Search data. Retrieved: September 13, 2026. I checked 3,944 query/page rows, 258 page rows, your repository’s keyword clusters, and the current live articles. The property recorded 150 clicks and 336,530 impressions during this period. What a website costs: compare quotes without surprises Refresh the existing Dutch article: https://straffesites.com/blog/wat-kost-een-website-laten-maken Why this topic: It has the largest observed opportunity of these three, with substantial visibility for specific cost questions. Query-level evidence for this page: “wat kost een website laten maken” 5,391 impressions · 0 clicks · 0% CTR · average position 14.77 “website laten maken kosten” 8,859 impressions · 1 click · 0.011% CTR · average position 17.27 Whole-page context: 125,547 impressions and 33 clicks. Writing angle: Turn the existing quote-comparison advice into a checklist readers can use alongside an actual proposal. Cover included work, revisions, content responsibilities, recurring costs, ownership, and exclusions. Keep the sourced market benchmarks already present. Ownership warning: “goedkope website laten maken” appeared on both the budget article (3,548 impressions) and this cost guide (49). Online-store cost queries also overlap: “wat kost een webshop laten maken” received 116 impressions on this general guide and 43 on the dedicated online-store cost article. Keep budget-saving advice and online-store pricing detail on their respective pages. These overlaps are cannibalization signals, not proof of ranking damage. Timing: This article received a substantive update on September 11, after the report ends. Review its performance no earlier than October 11 before making another SEO-driven rewrite. Writing prompt: Refresh the existing Dutch website-cost guide for Belgium and the Netherlands. Develop its quote-comparison section into a practical checklist covering scope, revisions, content, hosting, maintenance, ownership, and exclusions. Preserve sourced market figures with their dates and context. Do not invent prices or publish Straffe Sites rates. Link to the existing budget and online-store cost guides instead of duplicating them. Astro and Prettier: setup checks and formatting fixes Refresh the existing US English article: https://straffesites.com/en/blog/integrate-prettier-astro-tailwindcss Why this topic: Its main formatting queries already average positions around 6–7, closer to prominent results than the other two recommendations. Query-level evidence for this page: “astro prettier” 422 impressions · 1 click · 0.237% CTR · average position 6.88 “prettier astro” 376 impressions · 0 clicks · 0% CTR · average position 6.11 “prettier-plugin-astro” 218 impressions · 1 click · 0.459% CTR · average position 6.11 Whole-page context: 4,295 impressions and 14 clicks. Writing angle: The article already explains installation, plugin order, and Tailwind stylesheet configuration. Add a short diagnostic path for formatting failures rather than another setup walkthrough: does formatting work from the command line, does the editor use the same configuration, and does class sorting work separately? Ownership: Keep formatting on this dedicated guide. The broader Astro starter guide received only 6 impressions for “astro prettier,” compared with 422 here. The historical keyword registry flags overlap, but the current report does not show substantial competition for this query. Writing prompt: Refresh the existing Astro/Prettier guide in US English. Preserve the configuration and add troubleshooting that separates command-line formatting, editor integration, and Tailwind class sorting. Verify current official documentation and test examples before claiming they work. Keep general Astro/Svelte/Vercel setup in the existing starter guide and link to it. Set up Google Search Console and fix verification problems Refresh the existing US English article: https://straffesites.com/en/blog/google-search-console Why this topic: Google already shows the guide for clear setup intent, but those impressions produce few clicks. Query-level evidence for this page: “how to set up google search console” 1,649 impressions · 0 clicks · 0% CTR · average position 14.60 “google search console setup” 1,033 impressions · 1 click · 0.097% CTR · average position 14.28 Whole-page context: 8,677 impressions and 5 clicks. Writing angle: Keep the existing three-step setup and practical reporting workflow. A useful next extension is concise verification troubleshooting: choosing the correct property, finding the authoritative DNS provider, placing the TXT record, and distinguishing verification delays from missing report data. Ownership and timing: The English guide is the clear owner for these setup queries. Preserve its Dutch counterpart rather than merge languages. The September 9 refresh already improved the reporting instructions and citations; review its results no earlier than October 9 before expanding it again. Writing prompt: Review the September 9 update before refreshing this US English guide. Preserve the setup steps and page/query workflow. Add concise verification troubleshooting supported by current Google documentation. Separate setup time from DNS waiting time and sitemap discovery from indexing. Do not promise immediate data or ranking gains. Evidence limits These are observed search opportunities, not traffic forecasts. GSC omits anonymized queries, and average position is not a fixed ranking. Low CTR alone does not establish a title problem. Country/page and device/page reports were also retrieved, but their totals did not reconcile with page-only data, including after a device-report recheck. I have not used them to claim audience shares. The proposed troubleshooting sections are editorial extensions of demonstrated broader intent, not independently proven high-volume keywords. No articles, publication dates, or shared calendars were created or changed. Show more 2 of 2 messages Search Console describes searches where your site appeared. It is not a market-wide keyword-volume tool, and sparse data should not become a confident demand forecast. Refreshing an existing article can be a better choice than adding a competing page. Improve the draft in the same conversation Back in the writing conversation, this follow-up revises the Astro-versus-WordPress draft using the developer-focused outline above: Hermes Agent: revise the draft in the same conversation gpt-6-astra You /notfair-content-writer Revise the draft above. Keep the code examples, cut generic advice, and make the explanation easier to follow. Agent SEO metadata Title: Astro vs WordPress: what developers maintain after launch Meta description: Astro vs WordPress for developers maintaining small business sites. Compare updates, publishing, integrations, recovery, and the work each setup leaves you. Proposed slug: /en/blog/astro-vs-wordpress Primary keyword: Astro vs WordPress Secondary topics: Astro maintenance, WordPress maintenance, static-site deployment, headless WordPress. The earlier article contained no implementation code examples. I kept the technical explanations and updated its JSON-LD rather than introducing untested code. Astro vs WordPress: what developers maintain after launch A static Astro site can remove a WordPress application and database from the public request path. It cannot remove the developer responsible for publishing changes, fixing forms, and recovering from a bad release. For developers comparing Astro vs WordPress for small business websites, that ongoing work is a better starting point than a framework benchmark. Choose static-first Astro when the site mostly publishes content and you can support its editing and deployment workflow. Keep WordPress on the shortlist when its editor or existing plugins already handle the business's requirements. A working WordPress site does not need a migration just because you would prefer to maintain Astro. This comparison assumes conventional WordPress with sensible caching, not an intentionally slow installation. On the Astro side, it starts with prebuilt pages. On-demand rendering and headless WordPress add responsibilities of their own. Contents Astro vs WordPress: what becomes your responsibility? Follow a content change through to production Separate failed updates from broken production Trace forms and bookings beyond the frontend Headless WordPress leaves you with two systems Make the decision against a real maintenance brief Frequently asked questions Astro vs WordPress: what becomes your responsibility? A conventional WordPress installation runs application code and stores content in a database. That does not mean every visitor triggers a fresh database query. WordPress's caching documentation describes serving cached static files; uncached requests and dynamic features still need the application. Astro prerenders routes by default. For those routes, the host serves the files produced by the build. You maintain the system that creates and delivers those files rather than a CMS application serving public pages. Maintenance task Static-first Astro Conventional WordPress Publish content Edit files or use a connected CMS, then build and deploy Publish through the editor; check cache behavior Update software Framework, packages, build environment, and integrations Core, themes, plugins, and the hosting runtime Recover content Restore source content or CMS data; rebuild if needed Restore revisions or appropriate database and file backups Recover a release Restore a known-good deployment or rebuild a reverted version Restore compatible application code and account for database changes Investigate missing inquiries Trace the form endpoint, provider, and delivery Trace the plugin or endpoint, provider, and delivery For a fully static frontend, removing WordPress also removes its core, theme, and plugin update cycle. Repository access, deployment accounts, hosting, and external services remain. A compromised deployment account can replace a static site just as effectively as a compromised application can alter a dynamic one. If you add Astro's on-demand rendering, you also need an adapter and runtime. Include those in the maintenance plan. The relevant distinction is which code runs where, not whether the project has an Astro logo. Follow a content change through to production Suppose the client asks you to update a service description and replace its photo. The task is finished when the public page shows the approved content, with the right image and working links. WordPress: check the saved content, then the response The block editor provides the editing interface. Preview the change, publish it, and check the page as a logged-out visitor. An administrator's view may bypass caching or show content that an ordinary visitor cannot see. If the old description remains visible, first confirm the right page was updated and published. Then inspect the page cache and CDN behavior. If only the image is stale, check the image URL and its caching separately. Purging every cache before identifying the stale response can hide the cause. Astro: check the source, build, deployment, and public page With file-based content, the change passes through the repository and build before it reaches production. A CMS adds an editing interface, but a statically built frontend still needs a successful publication path. Straffe Sites documents one file-based approach in its article about a website without a CMS: content lives as MDX and JSON in Git, with Astro Content Collections validating configured fields. That is an example of a technical team's workflow, not a requirement for every Astro project. When an update is missing, check the stages in order: Does the intended source contain the new content? Did the build use that source revision or CMS version? Did the build and deployment succeed? Does the production domain serve that deployment? Is a cached page or asset hiding the change? A CMS saying "published" answers only the first part of this chain. Give editors a way to tell whether their change reached the website, and assign someone to investigate failures. Otherwise routine publishing problems become unexplained support tickets. Separate failed updates from broken production The following are hypothetical failure scenarios, not reports of tests performed for this article. A WordPress plugin update breaks the form After a plugin update, the contact page still loads, but submissions fail. Start by reproducing a submission with test data. Inspect the browser request and the relevant server or provider logs. Determine whether the failure occurs before the request, at the endpoint, or during onward delivery. Before restoring an older plugin version, check whether the update changed stored data and whether the older code can read it. Restoring files alone may not reverse a database migration. Restoring an entire database backup may also discard newer inquiries, bookings, or orders. This is why the recovery plan must identify both the code version and the state it expects. WordPress's security guidance covers updates and recovery preparation; the separate WordPress maintenance guide provides broader context. For this incident, the useful acceptance test is a submitted inquiry reaching its destination. An Astro dependency update prevents the next deployment An Astro update can fail during dependency installation, validation, or the build. Check the first relevant error and compare the changed dependency versions and runtime requirements. Use the project's lockfile and documented build environment rather than trying unrelated package upgrades. A failed build is not necessarily an outage. A deployment system that retains the previous successful release until its replacement is ready can keep serving the old site. A script that deletes or overwrites live files before finishing the build cannot make the same promise. Verify the host's behavior instead of attributing that protection to Astro. A successful build can still publish the wrong content or a broken form. Check the deployed page and critical interactions after release. Restoring a previous deployment reverses that deployment's files; it does not automatically reverse changes in an external CMS, form service, or database. For either stack, document what "rollback" restores and what it leaves untouched. Recovery should not begin with someone discovering where the backups are. Trace forms and bookings beyond the frontend An HTML form on a static page still needs somewhere to send its data. A WordPress form plugin also depends on processing and delivery beyond the visible form. In both cases, trace the complete path: Visitor submission → receiving endpoint → stored record or delivery queue → staff notification or CRM. Check each boundary. Did the endpoint accept the submission? Was a record stored? Did the notification arrive? An accepted API request and a delivered email are different events. The confirmation message should accurately describe what the system knows. Keep the failure check small and repeatable: submit identifiable test data without private customer details, verify the destination, and remove the test through the agreed operational process. Check invalid input and unavailable-provider behavior as well as the successful path. Never use real charges to test a checkout when the provider supplies a test mode. Do not rebuild working business operations by accident A booking link to an existing scheduling service is a small frontend feature. Replacing a WordPress plugin that manages availability, deposits, and cancellations is a different project. List those behaviors before estimating a migration. WooCommerce is a commerce platform for WordPress. Astro can render a storefront connected to a commerce backend, but it does not supply order management by itself. The new setup still needs someone responsible for payment events, inventory changes, refunds, and failed notifications. Retain an established integration when it works unless the replacement solves a specific problem. Moving complexity into custom code or another provider does not make it disappear from your maintenance workload. Headless WordPress leaves you with two systems With headless WordPress, editors retain WordPress while Astro renders the public site. Astro's WordPress integration guide describes fetching content through the WordPress REST API. The broader headless CMS explanation covers the separation between editing and presentation. For a statically built frontend, you now own the connection between two publication states: content published in WordPress and content deployed by Astro. Define how publication triggers a build, how a failed build is reported, and how an editor previews a draft without exposing it publicly. Audit the plugins before committing to this design. A plugin that modifies a WordPress template, inserts frontend scripts, or renders a form will not automatically reproduce that behavior in Astro because the content API is available. Rendering CMS HTML also requires a clear trust boundary; inserting a string as HTML is not a sanitization step. Headless WordPress is justified when preserving the editorial workflow has value and a separate frontend meets a concrete requirement. If the conventional site already works, adding a second deployment system solely to change frameworks is hard to justify. Make the decision against a real maintenance brief Consider a hypothetical electrical contractor with eight service pages, a project gallery, a contact form, and an external scheduling service. The developer handles occasional content changes. Static Astro fits that brief: prebuilt pages, a defined form endpoint, and a link to the existing scheduler. The maintenance agreement still needs a response time for urgent content corrections and a backup maintainer who can publish them. If an office manager must publish projects independently every week, include an editor in the Astro proposal and compare the resulting setup with WordPress. If bookings and payments already depend on a working WordPress plugin, keeping WordPress may avoid a substantial integration rewrite. Test the actual site before using speed to justify a move Astro's islands architecture lets you add interactive components without hydrating the entire page. That is useful control over browser work, but a booking embed, large image, or added script can still dominate performance. Compare representative pages with the same required content and integrations. Record lab conditions, check mobile behavior, and use available real-user data as a separate source. Do not compare an empty Astro demo with a full production WordPress page. Google states that good Core Web Vitals do not guarantee top rankings. A platform change needs its own operational justification. If you migrate, preserve useful URLs and verify redirects, metadata, internal links, and indexability rather than treating the rebuild as an automatic SEO improvement. Before recommending a stack, put these answers in the handover document: Who publishes routine changes, and who handles urgent ones? Which endpoint receives inquiries, and how is delivery checked? What does the update process test before and after release? What survives a failed build, and what does rollback restore? Can another developer publish and recover the site using the documentation? Can the current site's problems be fixed without migration? Choose Astro when its publishing and delivery model removes work you would otherwise maintain. Choose WordPress when its editor and integrations already do that work well. Keep the existing site if a rebuild cannot explain what becomes simpler afterward. Frequently asked questions Does a static Astro site still need dependency updates? Yes. Static delivery removes the application runtime from prebuilt page requests, but the framework, packages, build environment, and integrations still need maintenance. Prioritize updates according to the affected component and its exposure. Can a failed Astro build take the live website down? That depends on deployment behavior, not Astro alone. A system that keeps serving the previous successful release while a replacement builds can preserve availability. A deployment script that removes live files first may not. Verify your setup. Does managed WordPress hosting remove the developer's maintenance work? No. The host may handle infrastructure, backups, or some updates. The developer still needs to know what the agreement covers and who tests custom code, plugins, forms, and business workflows after changes. When is headless WordPress worth maintaining? When retaining WordPress's editorial workflow and using a separate frontend solve concrete requirements. Account for both systems, including previews, API access, publication triggers, failed builds, and plugin behavior that must be recreated in the frontend. Accompanying publication notes Structured data This replaces the previous draft's headline, description, and FAQ content. JSON parsing and exact FAQ-text matching were checked. Publication-specific fields remain deliberately absent: author, dates, canonical URL, and image must reflect the actual approved publication. Image concepts are not published assets. FAQPage describes the visible questions; it does not promise Google FAQ rich results, which Google's previously verified documentation says are no longer shown. { "@context": "https://schema.org", "@graph": [ { "@type": "BlogPosting", "headline": "Astro vs WordPress: what developers maintain after launch", "description": "Astro vs WordPress for developers maintaining small business sites. Compare updates, publishing, integrations, recovery, and the work each setup leaves you.", "inLanguage": "en-US", "about": [ { "@type": "Thing", "name": "Astro" }, { "@type": "Thing", "name": "WordPress" } ] }, { "@type": "FAQPage", "inLanguage": "en-US", "mainEntity": [ { "@type": "Question", "name": "Does a static Astro site still need dependency updates?", "acceptedAnswer": { "@type": "Answer", "text": "Yes. Static delivery removes the application runtime from prebuilt page requests, but the framework, packages, build environment, and integrations still need maintenance. Prioritize updates according to the affected component and its exposure." } }, { "@type": "Question", "name": "Can a failed Astro build take the live website down?", "acceptedAnswer": { "@type": "Answer", "text": "That depends on deployment behavior, not Astro alone. A system that keeps serving the previous successful release while a replacement builds can preserve availability. A deployment script that removes live files first may not. Verify your setup." } }, { "@type": "Question", "name": "Does managed WordPress hosting remove the developer's maintenance work?", "acceptedAnswer": { "@type": "Answer", "text": "No. The host may handle infrastructure, backups, or some updates. The developer still needs to know what the agreement covers and who tests custom code, plugins, forms, and business workflows after changes." } }, { "@type": "Question", "name": "When is headless WordPress worth maintaining?", "acceptedAnswer": { "@type": "Answer", "text": "When retaining WordPress's editorial workflow and using a separate frontend solve concrete requirements. Account for both systems, including previews, API access, publication triggers, failed builds, and plugin behavior that must be recreated in the frontend." } } ] } ] } Image concepts Concepts only; no images generated or inserted. Featured illustration, after the opening paragraph Filename: astro-wordpress-maintenance.webp Alt: “Static publishing and WordPress application maintenance shown as separate workflows with shared integrations.” Concept prompt: Wide 16:9 editorial 3D diagram with two equally weighted workflows, connected to shared form and hosting services. Warm beige #E9E6DF, charcoal modules, paper panels, lime connectors. Avoid winner symbols, invented metrics, logos, and fake dashboard screenshots. Publishing-flow diagram, under “Follow a content change through to production” Filename: website-content-publication-paths.webp Alt: “WordPress publication and Astro build-and-deploy paths, each ending with a public-page check.” Concept prompt: Two horizontal process lanes. WordPress: edit, publish, cache, public page. Astro: source change, build, deployment, public page. Mark each diagnostic checkpoint. Use beige, charcoal, and lime; add labels during design production. Avoid timing claims and implied test results. Recovery comparison, under “Separate failed updates from broken production” Filename: website-release-recovery-boundaries.webp Alt: “Code, deployed files, and external data shown as separate recovery boundaries.” Concept prompt: A clear 4:3 technical diagram separating application files, static deployment artifacts, and persistent data. Show rollback arrows limited to their actual boundary. Neutral beige background, charcoal outlines, lime highlights. Avoid suggesting that restoring code also restores external data. Inquiry-delivery diagram, under “Trace forms and bookings beyond the frontend” Filename: website-form-delivery-checkpoints.webp Alt: “A form submission passing through an endpoint, storage or queue, and notification destination.” Concept prompt: Wide process diagram showing submission, endpoint acceptance, storage or queue, and notification or CRM as distinct checkpoints. Use simple labeled boxes, beige, charcoal, and lime. Avoid customer information, provider branding, and success badges presented as measured evidence. Internal linking The revision retains contextual links to the existing no-CMS, WordPress maintenance, and headless CMS articles. Those pages remain the detailed references; this article owns the developer-maintenance comparison. Suggested incoming links remain editorial recommendations only: - From the no-CMS article: “maintaining Astro versus WordPress.” - From the WordPress maintenance article: “whether a platform migration reduces maintenance.” - From the Astro-versus-Next.js article: “Astro versus WordPress after launch.” Before publication Confirm author, dates, route, and canonical destination. Produce the approved imagery and populate image metadata with real asset URLs. Integrate the revised schema without duplicating existing template output. Check rendered headings, links, table behavior, and mobile layout. Keep the failure scenarios labeled hypothetical; no execution evidence has been added. Change notes Shifted the explanation from owner-facing platform selection to developer responsibilities. Replaced broad advice with publishing checkpoints and specific failure scenarios. Clarified cache behavior, failed builds versus outages, and code rollback versus data recovery. Kept the small-business example, but tied each requirement change to maintenance work. Reused the already verified sources without rerunning the earlier broad research. Updated the metadata and FAQ schema. No website or external content was changed. Show more 2 of 2 messages You don't need to repeat the URL, audience, and full brief when they are already in the conversation. Point to the part you want changed and say what would make it more useful. Check the draft before you publish Read the article, check its sources, and run the code examples where safe. This next message continues the same writing conversation and asks Hermes to review the revised draft, fix what it can, and report what it could not verify: Hermes Agent: check facts, links, and code before publishing gpt-6-astra You Check this draft's facts, links, and code examples. Fix the issues and tell me what you couldn't verify. Don't publish it. Agent The draft is broadly accurate. I corrected seven passages, checked the links against their actual destinations, and validated the JSON-LD. Nothing was published or changed on the website. Checked on September 13, 2026. Review results All 11 original article links returned HTTP 200 and led to relevant pages. Both sources added during the corrections also returned HTTP 200. The corrected article has 13 working links. The seven table-of-contents entries match the headings using conventional Markdown slug rules. Final rendered anchors remain untested. The JSON-LD parses successfully, has no duplicate keys, and matches all four visible FAQ questions and answers. The article has no executable Astro, JavaScript, PHP, or shell examples. Its only accompanying code block is JSON-LD, which is data—not an implementation to run. Corrections Narrow the WordPress caching claim “Uncached requests … still need the application” was too broad. An uncached image or stylesheet can be served without running WordPress. Corrected passage: A conventional WordPress installation runs application code and stores content in a database. That does not mean every visitor triggers a fresh database query. WordPress's caching documentation describes serving cached static files; requests that generate a page or process a submission through WordPress still need the application. Static assets such as images and stylesheets can be served directly by the host or CDN. Source: https://developer.wordpress.org/advanced-administration/performance/cache/ Distinguish removing WordPress from replacing its frontend The original wording could suggest that a static frontend eliminates WordPress maintenance even when WordPress remains the CMS. It also made an unnecessary comparison between different kinds of compromise. Corrected passage: Retiring the WordPress installation removes its core, theme, and plugin update cycle. Replacing only the frontend does not: headless WordPress still needs maintenance. Repository access, deployment accounts, hosting, and external services also remain. Someone with permission to publish a deployment can change the public site, even when its pages are static. Sources: https://docs.astro.build/en/guides/cms/wordpress/ https://developer.wordpress.org/advanced-administration/security/hardening/ Make Git a workflow choice, not an Astro requirement File-based content does not inherently require a repository. Corrected passage: In a Git-based workflow, a file change passes through the repository and build before it reaches production. Git is a workflow choice, not an Astro requirement. A CMS adds an editing interface, but a statically built frontend still needs a successful publication path. The Straffe Sites example remains appropriate: its public no-CMS article describes MDX and JSON content in Git. That verifies the attributed example, not a requirement for every Astro site. https://straffesites.com/en/blog/website-without-cms Strengthen the plugin rollback instructions The draft correctly separated plugin files from database state. It needed two precautions: preserve the current state before recovery, and check whether downgrading would restore a known vulnerability. Corrected passage: Before restoring an older plugin version, preserve the current files and database. Check whether the update changed stored data, whether the older code can read it, and whether rolling back would reintroduce a known vulnerability. Test recovery on an isolated staging copy where possible. Restoring plugin files does not undo database changes. Restoring an older database can discard inquiries, bookings, or orders recorded after that backup. This is recovery guidance, not a claim that a particular plugin update or database migration was tested. Cite backup documentation directly The general hardening guide was relevant, but the backup documentation supports the files-versus-database explanation more directly. Corrected passage: WordPress's backup documentation explains why a typical full-site restore needs both files and the database. Its security guidance covers keeping software current. The separate WordPress maintenance guide provides broader context. New direct source: https://developer.wordpress.org/advanced-administration/security/backup/ Clarify deployment rollback versus rebuilding an old commit “Reverses that deployment’s files” was ambiguous. Serving an earlier build and rebuilding earlier source are different recovery operations. Corrected passage: Restoring a known-good static deployment puts its built files back into service. It does not automatically restore external CMS content, form-service data, database state, or separately managed hosting settings. Rebuilding an old commit is a different operation: external content, dependency resolution, or build settings may have changed since the original release. The existing warning about failed builds stays: retaining the previous live release is deployment-system behavior, not an Astro guarantee. I did not test a hosting provider’s rollback behavior. Make the HTML-rendering warning specific The draft’s sanitization warning was correct but abstract. Astro documents the relevant behavior explicitly. Corrected passage: Rendering CMS HTML also requires a clear trust boundary. Astro's set:html directive inserts HTML without automatically escaping it. Use it only for trusted HTML or content sanitized with an appropriate allowlist. Render untrusted plain text through Astro's normal escaped expressions instead. Source, including its checked fragment: https://docs.astro.build/en/reference/directives-reference/#sethtml No sanitizer implementation is included or claimed to have been tested. Facts that can stay The official sources support these central claims: Astro prerenders routes by default. On-demand rendering requires an adapter and a suitable runtime. https://docs.astro.build/en/guides/on-demand-rendering/ Astro islands allow selected components to become interactive without hydrating the whole page. That does not guarantee a fast site once images, embeds, and scripts are included. https://docs.astro.build/en/concepts/islands/ Astro can fetch WordPress content through the REST API. Making content available through an API does not automatically reproduce a plugin’s frontend behavior. https://docs.astro.build/en/guides/cms/wordpress/ WordPress provides a block editor, and WooCommerce provides commerce functionality for WordPress. Astro itself is not an order-management backend. https://wordpress.org/documentation/article/wordpress-block-editor/ https://woocommerce.com/ Good Core Web Vitals do not guarantee top Google rankings. The draft correctly avoids presenting a framework migration as an automatic SEO improvement. https://developers.google.com/search/docs/appearance/page-experience The remaining internal article links also worked. I checked their relevance to the passages that cite them; I did not audit every claim on those linked pages. JSON-LD and publication notes No JSON syntax correction was needed. The existing BlogPosting and FAQPage graph can remain as draft data. The distinction that matters: This JSON-LD has passed syntax and FAQ-content checks. It has not been validated inside a rendered page or submitted to Google’s Rich Results Test or Schema.org’s validator. Add the approved author, publication dates, canonical details, and real image assets before publication; do not invent values to complete the draft. The FAQ rich-result statement is also supported by current Google documentation. It should now include the direct citation rather than refer vaguely to “previously verified documentation.” Corrected note: FAQPage remains a Schema.org type, but Google states that FAQ rich results are no longer shown in Search. Keeping this graph is optional for describing the visible FAQ; it is not a recommendation for gaining a Google rich result. Sources: https://schema.org/FAQPage https://developers.google.com/search/updates#removing-faq-rich-result The Google changelog fragment exists and was checked. What I could not verify Actual failure recovery. I did not update plugins, install dependencies, restore databases, run builds, or deploy anything. Forms, bookings, payments, or email delivery. I submitted no test records and made no payment requests. Provider-specific guarantees. No particular hosting contract, backup retention policy, atomic deployment behavior, or rollback process was tested. Performance differences. No Astro-versus-WordPress benchmark was run. The draft makes no measured performance comparison. Final presentation. The unpublished draft has not been rendered, so mobile layout, table overflow, accessibility, actual heading IDs, and embedded JSON-LD remain unchecked. Image assets. They remain concepts. There are no generated images or asset URLs to validate. Publication metadata. Author attribution, publication dates, canonical destination, and image metadata still require approval. The hypothetical scenarios remain labeled as hypothetical. The corrected draft preserves the original argument without presenting documentation checks as hands-on testing. Show more 2 of 2 messages If Hermes can access your website repository, start it from that directory and ask it to save the approved draft using the project's existing format. A website URL alone does not give it filesystem or CMS access. My site uses MDX and JSON in Git with Astro; other sites can use their CMS's draft mode. Keep the publication decision yourself. Record the live URL, publication date, and any pre-change measurements. After at least 30 days, ask Hermes to compare the article's Search Console performance over comparable periods. For a new URL, track its first results rather than inventing a prepublication baseline. That's the monthly review pattern behind my SEO automation workflow, not a promise that every article will improve rankings. Troubleshooting before you blame the model The slash command is missing: check that the adapted skill is installed. Restart the session and check the exact command name. The skill still requests a hosted connector: ask Hermes to check the adaptation and its shared references. It should use the gcloud connection you approved. Google refuses access: ask Hermes to verify the actual identity and property permissions. Don't paste credentials into chat or grant broader rights blindly. The article feels generic: give it a specific question, your own example, or a technical opinion you can defend. Another writing pass cannot create missing experience. Start with one useful task. The skills contain the detailed procedures; your chat messages can stay short. For more on choosing a topic, drafting, and reviewing your work, see my AI writing workflow on Straffe Sites. The installation commands follow the linked official documentation. The installation and setup prompts are examples for your own environment, not transcripts of freshly completed installations or guaranteed results. The Agent Session blocks from “Turn the setup into an article” onward are recorded Hermes exchanges.