WordPress to Astro and Cloudflare migration

• WordPress

  • ✗ PHP, a database, and plugins to keep patched
  • ✗ Recurring hosting and backup cost
  • ✗ A login panel and constant bot scanning
  • ✗ Content locked in a database, hard to edit automatically
  • ✗ Performance depends on cache and plugin quality

• Astro + Cloudflare Workers

  • ✓ HTML, CSS, and images produced at build time
  • ✓ No database and no admin panel to break into
  • ✓ Content as Markdown in Git, with history and review
  • ✓ CDN, TLS, cache, and DDoS protection in one place
  • ✓ AI agents work on files instead of a CMS panel

The reasoning behind the stack is in choosing technology for a blog and company website in 2026, and the edge architecture in Cloudflare Workers and DNS.

• 1. WordPress → Astro — 800 PLN

  Up to 30 pages and posts, no shop and no user accounts.

  • ✓ Content and media exported to Markdown and WebP
  • ✓ Astro template built on semantic HTML and Pico CSS
  • ✓ Identical URL structure, 301 redirects for everything else
  • ✓ Title, description, canonical, sitemap, RSS, Open Graph
  • ✓ Contact form and a Git repository handed over to you

• 2. Migration to Cloudflare — 500 PLN

  One domain, Workers deployment, and configuration kept as Infrastructure as Code.

  • ✓ DNS zone transfer with existing records imported first
  • ✓ Worker with static assets, Custom Domain, and www redirect
  • ✓ Universal SSL, cache rules, and a WAF rule blocking /wp-, .php, .env probes
  • ✓ MX, SPF, DKIM, and DMARC stay DNS-only and are verified after the switch
  • ✓ OpenTofu configuration and wrangler.jsonc in your repository

Both services: 1200 PLN. A second site in the same order: −20%. Each page above the limit: 15 PLN. Rush delivery within 48 h: +50%.

Build a production Astro 7 website and migrate my WordPress content into it.

Inputs:
- WordPress XML export: [PATH_TO_XML]
- media: [PATH_TO_WP_CONTENT_UPLOADS]
- current website: [URL]

Requirements:
1. First inventory every public URL, title, meta description, heading, canonical, media file, and internal link. Save the report and a redirect map.
2. Use Astro 7 in static output mode. Do not add React, Vue, hydrated islands, a CMS, or a database.
3. Move posts into a type-safe content collection as Markdown with frontmatter. Build pages with custom layouts as simple .astro components.
4. Use semantic HTML and Pico CSS. Preserve the visual identity and information hierarchy, but remove WordPress theme, builder, and plugin code.
5. Convert images to WebP and preserve meaningful names, alt text, width, and height. Do not generate new images without approval.
6. Preserve existing URL paths. Add a permanent 301 redirect for every changed path.
7. Add title, meta description, canonical, Open Graph, sitemap.xml, robots.txt, RSS, and structured data where supported by the content.
8. Add a contact form with no secrets in source code and clear environment-variable configuration.
9. Add content validation, astro check, build, and a test covering old URLs, redirects, internal links, and missing pages.
10. Add a README with install, development, post publishing, and build commands.

Work in stages: audit, plan, implementation, validation. Do not delete content or change URLs without explaining why. Show results and risks after each stage. Finally run tests and the production build, fix failures, and list everything that still needs manual review.

Create a complete, minimal deployment stack in this repository for the existing static Astro website on Cloudflare.

Inputs:
- apex domain: [EXAMPLE.COM]
- optional www host: [WWW.EXAMPLE.COM]
- Cloudflare account ID will be supplied through CLOUDFLARE_ACCOUNT_ID
- tokens will only be supplied through CLOUDFLARE_API_TOKEN and TF_VAR_cloudflare_api_token

Requirements:
1. Configure Astro with output: "static" and Cloudflare Workers Static Assets. Do not add Pages or a Node server.
2. Add wrangler.jsonc with the Worker name, dist directory, ASSETS binding, and Custom Domain. The Worker must only perform necessary 301 redirects and pass every other request to env.ASSETS.fetch(request).
3. Add OpenTofu with pinned Cloudflare provider versions. Manage the zone, DNS records, Worker domain, www redirect, HTTPS/TLS, cache, and one custom WAF rule blocking /wp-, .php, and .env probes.
4. Inventory existing DNS records before changing anything. Never overwrite or proxy mail records. MX and hosts used by SPF, DKIM, and DMARC must remain DNS-only.
5. Never commit tokens, account ID, zone ID, tfstate, or secret .tfvars files. Add .gitignore and a value-free .env.example.
6. Use least-privilege token permissions and document them in README: Workers Scripts: Edit, DNS: Edit, and only when used WAF: Edit, Cache Settings: Edit, and Zone Settings: Edit.
7. Add commands for install, astro check, build, wrangler dev, wrangler deploy, tofu fmt, tofu validate, tofu plan, and tofu apply.
8. Document a safe rollout: staging, lower TTL, DNS backup, reviewed tofu plan, Worker deploy, nameserver switch, HTTPS/redirect/mail tests, and rollback.
9. Do not run tofu apply or change DNS without my explicit confirmation. You may run local validation and present a plan.

Inspect the existing files first and follow the repository's conventions. Then show a short plan, create the files, run validation, and fix failures. Finish with the created resources, required variables, token permissions, and manual cutover steps.

1. Create a Cloudflare account on your own company address and enable 2FA. The Free plan is enough for a typical static site.
2. Create an API token in the Cloudflare dashboard and send it over a secure channel, not by email. The deployment agent uses it: Wrangler publishes the Worker, OpenTofu manages DNS and edge policy.

Cloudflare defines Edit as CRUDL, so a separate Read permission adds nothing. We scope the token to a single zone, and after handover you can rotate or delete it in one click. Secrets never go into Git, tfvars, or shell history — they are passed as the CLOUDFLARE_API_TOKEN and TF_VAR_cloudflare_api_token environment variables.

You also keep registrar access for the nameserver change, and provide a WordPress export or a read-only WP account.

1. Inventory. URLs, metadata, media, and DNS records, together with the redirect map.
2. Content conversion. Posts and pages become Markdown, images become WebP, the layout becomes Astro components.
3. Staging. A review build on a separate hostname with a separate token.
4. Verification. URLs, titles, descriptions, sitemap, and redirects compared against the pre-migration state.
5. Cutover. wrangler deploy, then an approved tofu plan and tofu apply for DNS and the Custom Domain.
6. Handover. Repository, publishing instructions, and a short walkthrough of editing Markdown.

• Out of scope

  WooCommerce, user accounts, payments, booking systems, and redesign. The migration reproduces the existing layout or uses a simple template. Those items are quoted separately.

• Running costs

  The domain and any mailbox hosting. On the Workers Free plan static assets are unmetered, while the Worker has 100,000 requests per day and 10 ms CPU per invocation.

• Optional care

  Dependency updates, monitoring, content changes, and further development, hourly or on a retainer, once the scope is agreed.