robbertvanempel/wordpresstowebsite-community

WordPress to Website Community

Turn an existing WordPress site into a maintainable custom website without treating the redesign as a blank slate. Preserve the source first, translate the requested design direction into an original visual system, then build and prove migration parity.

Match the user's language. Do not repeat questions already answered in the request or available project context.

Start with intake

Before crawling the source, creating files, choosing a framework, or proposing a visual design, read references/intake.md and ask one compact round containing only the unanswered essential questions.

The initial round must establish at least:

• the current WordPress URL;
• the migration scope and any non-public content;
• the desired style, described directly and/or through example URLs;
• the intended deliverable and destination;
• required functionality, languages, branding, and launch constraints;
• confirmation that the user may migrate the supplied content and assets.

Accept “you decide” for design and implementation choices. A source URL, an actionable scope, and permission to use the source material cannot be invented. Never ask the user to paste passwords, API keys, cookies, database credentials, or recovery codes into chat. Request an export file or an approved secure access method only when public discovery is insufficient.

After the user answers, summarize the agreed brief, explicit defaults, unresolved unknowns, and exclusions. Ask a follow-up only when an answer would materially change preservation, architecture, cost, or deployment.

Separate discovery, build, and launch

Treat these as distinct authorization boundaries:

1. Discovery: inspect public pages, APIs, sitemaps, feeds, and supplied exports without changing the source site.
2. Build: create or modify the destination project while leaving the source site available.
3. Launch: deploy, change DNS, replace hosting, add redirects, or retire WordPress only when the user explicitly authorizes that action.

Do not interpret permission to analyze or build as permission to publish. Prefer a staging or preview URL for review. Never delete or disable the WordPress site until the new site is accepted and a recoverable backup exists.

Preserve the source before transforming it

Read references/preservation.md before collecting content or media.

Build a source inventory before implementation. Use the strongest sources available: a WordPress export or authenticated API when supplied, then the public REST API, WordPress sitemaps, ordinary sitemaps or feeds, and finally a bounded HTML crawl. Combine sources when one is incomplete.

Record every in-scope item and its migration status. Cover pages, posts, custom post types, taxonomies, authorship, dates, slugs, internal links, SEO fields, structured data, attachments, featured images, inline media, alt text, captions, downloadable files, and required interactive features.

Preserve original media bytes when they are accessible and authorized. Record the original URL, destination path, MIME type, dimensions where applicable, byte size, SHA-256 hash, references, alt text, caption, and outcome. Never claim a public crawl includes drafts, private posts, unpublished revisions, form submissions, user accounts, plugin settings, or original media files that were not publicly reachable.

Keep raw exports, database dumps, credentials, and private media out of version control by default. Do not store user content, brand assets, or credentials inside this installed skill folder.

Translate style instead of cloning identity

Read references/design-direction.md when the user provides an example URL, screenshots, brand material, or an open-ended style request.

Analyze references into reusable characteristics such as hierarchy, spacing, typography roles, palette behavior, image treatment, shapes, density, motion, and navigation patterns. Ask what the user likes or dislikes when that is unclear. Produce a short design-direction summary before implementing high-cost visual work.

Create an original design. Do not copy another site's source code, text, logos, illustrations, proprietary assets, or distinctive trade dress without permission. A reference URL authorizes analysis, not duplication. Preserve supplied logos and brand assets exactly unless the user authorizes edits.

Choose architecture from the requirements

Do not force a fashionable stack onto the project. Choose based on editing needs, content volume, interactivity, integrations, hosting, maintainability, and the user's technical comfort.

• Prefer static generation or server rendering for content-heavy public sites where SEO and performance matter.
• Add a CMS only when non-technical editing is required; explain who will edit what after launch.
• Preserve existing public paths when practical. Otherwise create explicit permanent redirects for every changed in-scope URL.
• Model repeatable content as structured data instead of pasting it into page components.
• Keep imported content and media provenance traceable to the source inventory.
• Preserve required analytics, consent, forms, search, ecommerce, memberships, embeds, and integrations only when they are in scope and testable.

Do not silently carry forward vulnerable plugins, tracking scripts, obsolete shortcodes, or WordPress-specific markup. Convert useful meaning and behavior, and report anything that requires replacement or manual review.

Build in migration slices

Implement one representative content type or route first when the project is large. Validate its content model, media handling, style system, and responsive behavior before scaling the migration.

Keep a route map and content/media manifests current as work proceeds. For each skipped item, record a reason such as out-of-scope, duplicate, private-unavailable, broken-at-source, or requires-user-decision. Never make missing items disappear from the audit trail.

Honor the existing destination repository, framework, conventions, and unrelated user work. Do not overwrite a non-empty project or replace an existing implementation without explicit direction.

Verify parity and quality

Read references/verification.md before calling the migration complete.

Verify the built or deployed site against the manifests, not from memory. At minimum, prove:

• every in-scope source URL is represented by a destination page or an intentional redirect;
• titles, meaningful body content, dates, authors, taxonomy, and SEO metadata survived where required;
• every referenced local asset resolves as the expected media type, not an HTML fallback with status 200;
• image dimensions, alt text, captions, downloads, internal links, canonical URLs, sitemap entries, and structured data are correct where applicable;
• scoped forms, search, analytics, consent, ecommerce, authentication, embeds, and integrations work end to end;
• representative mobile and desktop pages have no obvious accessibility, overflow, console, or performance failures.

Use byte hashes when the requirement is to preserve original files. Use visual review for crops, responsive art direction, layout, and transformations where byte equality is intentionally impossible.

Do not report “nothing was lost” unless all in-scope inventory rows have a verified destination or an accepted exception. Distinguish local build checks, preview verification, production verification, and items that could not be accessed.

Deliver a migration record

Adapt filenames to the destination project, but provide the equivalent of:

• migration-brief.md: scope, design direction, architecture, assumptions, and exclusions;
• source-inventory.csv or .json: source content and route inventory;
• media-manifest.csv or .json: source/destination media mapping and hashes;
• redirect-map.csv: old URL, new URL, redirect status, and verification result;
• the new website source code and content;
• verification-report.md: parity, browser, functional, SEO, and accessibility evidence;
• handover.md: editing, deployment, rollback, backups, and remaining manual work.

Keep sensitive exports outside a public repository and reference their secured location without exposing secrets.

Stop conditions

Pause and explain the exact gap when:

• the source URL or authorized scope is unknown;
• robots, authentication, rate limits, or hosting controls prevent safe discovery;
• essential private content is not present in a supplied export;
• the requested design depends on copying assets or identity the user may not use;
• launch requires credentials, DNS changes, purchases, destructive replacement, or other authority not yet granted;
• parity cannot be proven from the available source.

Offer the smallest safe next step. Do not disguise an incomplete crawl, a working homepage, or a successful build as a completed migration.