Prompts to Clone Any Website Into WordPress

MASTER PROMPT: Pixel-Accurate Website Cloner (v3)

You are an expert front-end engineer specializing in pixel-accurate website cloning, interaction recreation, responsive design, and front-end reverse engineering.

TARGET WEBSITE
<YOUR_WEBSITE_URL>

Your job is to recreate this website as a clean, self-contained, editable static project that looks and behaves as closely as possible to the original.

The clone must reproduce:
- The same visual hierarchy
- The same layout
- The same typography
- The same spacing
- The same colors
- The same images/videos
- The same responsive behavior
- The same scroll animations
- The same interactive effects
- The same hover behavior
- The same important transitions and micro-interactions

The goal is not merely to create something visually similar. The goal is to reconstruct the actual rendered experience of the website.

0. GOLDEN RULE: CLONE WHAT YOU SEE, NOT JUST THE CODE

This is the most important rule. Modern websites built with Astro, React, Vue, Next.js, Webflow, GSAP, Three.js, custom animation systems, etc. often generate or load their actual styling, layout, animations, and assets at runtime.

Therefore:
- Never assume that the downloaded HTML represents the actual website.
- Never build the clone from downloaded HTML alone.

Before writing a single line of code, establish the website's ground truth. Follow this order:

Step 1: Inspect the live website
Open the live website in a real browser. Capture full-page screenshots at:
- Desktop
- Tablet
- Mobile
Also inspect important sections at different scroll positions. The screenshots are the primary visual reference for the entire reconstruction.

Step 2: Inspect the rendered DOM
Inspect the actual rendered elements in the browser. Determine:
- Section structure
- Container widths
- Grid/flex relationships
- Element positioning
- Absolute/fixed/sticky elements
- Image containers
- Background layers
- Text blocks
- Buttons
- Cards
- Navigation
- Footer
- Hidden/revealed elements
Do not rely only on the original source HTML.

Step 3: Inspect computed styles
For important elements, determine the actual rendered values. Inspect:
- Font family, font weight, font size, line height, letter spacing, text transform
- Color, background color, gradient
- Width, height, padding, margin, gap
- Border, border radius, box shadow, opacity
- Position, z-index, transform
- Object-fit, object-position
- Maximum width, minimum width
- Responsive behavior

Pay special attention to images. Determine whether an image is:
- Full-bleed
- Contained
- Cropped
- Background image
- Inline image
- Absolutely positioned
- Centered
- Left/right aligned
- Using object-fit: cover
- Using object-fit: contain
Do not guess these values.

Step 4: Inspect scripts and animation logic
If the styling or animation behavior is not obvious from the rendered DOM, inspect the site's JavaScript and loaded resources. Look for:
- GSAP, ScrollTrigger, Lenis, Framer Motion
- Three.js, WebGL, Canvas
- IntersectionObserver
- CSS animations, CSS transitions
- requestAnimationFrame
- Image sequences, video sequences
- Scroll-based transforms
- Sticky/pinned sections
- Custom cursor systems
You do not need to copy the original libraries. Understand the behavior and recreate it using vanilla JavaScript wherever possible.

1. CAPTURE THE EXACT LAYOUT

For every section, verify the actual arrangement before coding. Do not create a generic interpretation. Determine:

Hero
- Is it centered?
- Split layout?
- Text left/image right?
- Text right/image left?
- Full-screen?
- Full-bleed?
- Background image?
- Video?
- Floating objects?
- Overlapping cards?

Content sections
- Number of columns
- Column widths
- Section height
- Container width
- Alignment
- Spacing
- Image positioning
- Text positioning
- Card positioning

Floating elements
Determine exactly where badges, cards, statistics, labels, buttons, decorative elements, images, and shapes are positioned.

Backgrounds
Determine whether backgrounds are:
- Flat colors
- Gradients
- Images
- Videos
- Multiple layered backgrounds
- Noise/grain textures
- SVG patterns

Match the original composition rather than defaulting to a standard centered layout.

2. CAPTURE ALL SCROLL ANIMATIONS & INTERACTIVE EFFECTS

The original website's feel often comes from motion. Do not flatten everything into simple fade-in animations. Identify and reproduce the actual behavior wherever present.

Scroll behavior
Look for:
- Sticky sections
- Pinned sections
- Scroll-scrubbed animations
- Horizontal scrolling sections
- Scroll-driven image scaling, rotation, translation, opacity, clipping, and masking

Image sequences
If the original uses numbered image frames:
- Identify the complete sequence.
- Download all required frames.
- Preserve the correct ordering.
- Reproduce the scroll-scrub behavior.
- Maintain the correct frame timing.
- Use canvas or another appropriate vanilla JS implementation if necessary.
Do not replace an actual frame animation with a static image.

Reveal effects
Reproduce effects such as:
- Blur to sharp
- Opacity reveal
- Clip-path reveal
- Mask wipe
- Image expansion
- Image cropping
- Scale reveal
- Line-by-line, word-by-word, and character-level text reveals
- Staggered element reveals

Parallax
Identify elements moving at different speeds. Recreate:
- Background parallax
- Image parallax
- Text parallax
- Decorative object movement
- Multi-layer depth effects

Hover and cursor interactions
Inspect and recreate:
- Button, image, and card hover
- Cursor-following effects
- Magnetic buttons
- Spotlight effects
- Underline animations
- Scale effects
- Color and border transitions
- Image distortion
- Micro-interactions

Other interactions
Preserve:
- Counters
- Sliders and carousels
- Accordions and tabs
- Dropdowns
- Navigation menus and mobile hamburger menus
- Modal interactions
- Tooltips
- Form interactions

Match the original timing, easing, trigger points, and start/end values as closely as possible.

Respect prefers-reduced-motion: when reduced motion is enabled, heavy animation should be disabled or significantly reduced.

2A. TECHNOLOGY STRATEGY

The reconstructed source project must use:
- HTML5
- CSS3
- Vanilla JavaScript

Do NOT use:
- React, Vue, Angular, Svelte
- Tailwind build systems
- SASS
- TypeScript compilation
- npm build systems
- Framework-specific build tools

The final project must remain easy to understand and edit. Third-party libraries should only be used when genuinely necessary. If a library is required for the source version, prefer a CDN only when appropriate.

However, the root offline index.html must not depend on any external CDN or network resource. Therefore, any dependency required by the offline version must either:
- Be replaced with vanilla JavaScript, or
- Be embedded/self-contained in the root file where legally and technically appropriate.

Do not create runtime network dependencies.

2B. PROJECT STRUCTURE

The final project MUST contain:

project/
├── index.html
├── START-HERE.bat
└── source/
    ├── index.html
    ├── css/
    │   └── style.css
    ├── js/
    │   └── script.js
    └── assets/
        ├── images/
        ├── videos/
        ├── fonts/
        └── frames/

The two versions serve different purposes.

2C. ROOT INDEX.HTML: OFFLINE DOUBLE-CLICK VERSION

This requirement is VERY IMPORTANT. The top-level index.html must work when the user simply double-clicks it. It must work under file:// with:
- No local web server
- No npm
- No build process
- No internet connection
- No external resource requests

The root index.html must therefore be a single self-contained HTML file.

CSS
Inline ALL CSS directly inside <style>...</style>. Do not reference css/style.css from the root file.

JavaScript
Inline ALL JavaScript directly inside <script>...</script>. Use normal non-module JavaScript. Do NOT use <script type="module">. Do not depend on JavaScript modules that require server execution.

Images
Every image used by the root version must be embedded directly into the HTML as a data: URI, for example data:image/webp;base64,... No external image URL may be required.

SVG
SVG assets should be embedded directly where practical, using inline SVG, a data URI, or another fully self-contained approach depending on the implementation.

Video
Every required video must also be self-contained. Where technically feasible, embed video as a data URI. If the original experience uses video, reproduce it in the offline version without making a network request. If embedding the original video would make the file exceed the size limit or is technically impractical, implement the closest faithful offline-compatible alternative and document the limitation clearly.

Fonts
Fonts must also be self-contained. Do not use the Google Fonts CDN or any other external font request in the root offline version. Embed required fonts as data:font/... where technically possible. If a font cannot legally or technically be embedded, use the closest appropriate local fallback and clearly document the limitation.

No runtime network requests
The root file must not attempt to fetch images, fonts, CSS, JavaScript, JSON, APIs, external libraries, or CDN resources at runtime.
- Do not use fetch() for required page resources.
- Do not depend on XMLHttpRequest for page assets.
- Do not dynamically request external resources.

File size limit
The completed root index.html must remain 16 MB or less. Keep responsive images and embedded assets reasonably optimized. Before delivery:
- Check the actual file size.
- Optimize oversized images.
- Avoid unnecessary duplicate assets.
- Avoid embedding unused assets.
- Compress images where possible.

2D. SOURCE VERSION: CLEAN & EDITABLE

The clean source version must live inside source/ and follow:

source/
├── index.html
├── css/
│   └── style.css
├── js/
│   └── script.js
└── assets/

This version is intended for editing, debugging, development, WordPress conversion, future component extraction, easy asset replacement, and easy CSS modification.

Source HTML
Use semantic HTML5: <header>, <nav>, <main>, <section>, <article>, <footer>. Keep the HTML clean and readable.

Source CSS
All CSS must be located in source/css/style.css. Organize it logically by:
- Reset/base
- Typography
- Global layout
- Header
- Hero
- Sections
- Components
- Animations
- Responsive styles
Do not use inline styles unless technically unavoidable.

Source JavaScript
All JavaScript must be located in source/js/script.js. Keep it clean, commented, modular in organization, easy to understand, and free of unnecessary complexity. Do not use framework-specific JavaScript.

2E. ASSET MANAGEMENT

Every required asset for the source version must be stored locally in source/assets/, with optional subfolders: images/, videos/, fonts/, frames/, icons/.

Rename assets clearly. For example:
- hero-background.webp
- hero-product.webp
- logo.svg
- feature-card-01.webp
- ring-frame-001.webp
- ring-frame-002.webp
- ring-frame-003.webp

Do NOT retain meaningless random filenames such as 8f73ab2.webp, image_39482.png, or chunk-a91d3.svg unless there is a technical reason.

Update every source path to point to the local asset. Do NOT hotlink original assets.

3. CLONING REQUIREMENTS

The clone must reproduce:
- Header
- Navigation
- Hero
- Every visible main section
- CTA sections
- Cards
- Images
- Backgrounds
- Footer
- Mobile navigation
- Important interactive elements

Match layout, spacing, colors, typography, border radius, shadows, image cropping, responsive behavior, animation, and interaction as closely as possible.

4. RESPONSIVE REQUIREMENTS

The website must work correctly at:
- Desktop: large desktop and standard laptop widths
- Tablet: tablet and medium-width layouts
- Mobile: small smartphone widths

Do not simply shrink the desktop layout. Determine how the original actually changes between breakpoints. Check navigation, typography, image placement, section height, grid columns, card stacking, padding, margins, button sizing, text wrapping, and animation behavior.

No horizontal scrolling should exist at any supported width.

5. CODE QUALITY

The source project must have:
- Semantic HTML5
- Clean CSS
- Organized JavaScript
- Meaningful class names
- Useful comments
- No unnecessary duplication
- No broken asset paths
- No broken links
- No console errors
- Valid markup
- Responsive behavior

Avoid unnecessarily complicated implementations. If the original effect can be recreated simply with CSS or vanilla JavaScript, prefer the simpler solution.

6. PERFORMANCE

The clone should remain lightweight. Avoid:
- Unnecessary libraries
- Duplicate assets
- Excessive JavaScript
- Unnecessary animation loops
- Huge unoptimized images
- Excessive DOM elements

For animations:
- Prefer CSS transforms and opacity where appropriate.
- Use requestAnimationFrame carefully.
- Avoid forced synchronous layout where possible.
- Use lazy loading where it does not interfere with the original experience.
- Avoid continuously running effects when they are not visible.

The visual result should remain faithful without introducing unnecessary performance overhead.

7. VERIFY BEFORE DELIVERY: DO NOT SKIP

Verification is mandatory. Do not deliver immediately after coding.

7A. Test the SOURCE version
Run the source project through START-HERE.bat. The batch file should:
- Start a tiny local web server.
- Serve the source/ directory.
- Automatically open the browser.
The source version must work correctly through the local server.

7B. Test the ROOT OFFLINE version
The top-level index.html must be tested by double-clicking the file directly. It must open through file:// and function correctly. The test must be performed with network access unavailable/disabled where practical. Confirm that:
- CSS loads because it is inline.
- JavaScript runs.
- Images display.
- Fonts display.
- Videos work where embedded.
- Animations work.
- Interactions work.
- No network resource is required.
- No console errors occur.

7C. VISUAL COMPARISON
Compare the clone against the original screenshots. Check:
- Layout: section heights, container width, columns, alignment, padding, margins, positioning
- Typography: font, weight, size, line-height, letter spacing, wrapping
- Visuals: colors, gradients, images, cropping, borders, shadows, radius
- Motion: scroll timing, easing, reveal position, pinning, parallax, scrubbing, hover effects, transitions
- Responsive: desktop, tablet, mobile
Fix discrepancies before delivery.

7D. FINAL QUALITY CHECK
Before packaging, verify:
- No horizontal scrolling.
- No overlapping elements.
- No missing images.
- No broken fonts.
- No broken videos.
- No broken links.
- No console errors.
- No missing animations.
- No missing interactions.
- Mobile menu works.
- Buttons work.
- Sliders work.
- Accordions work.
- Counters work.
- Hover effects work.
- Scroll effects work.
- Reduced-motion behavior works.
- Root index.html works by double-click.
- Root index.html works offline.
- Root index.html is 16 MB or less.
- Source version works through START-HERE.bat.

8. START-HERE.BAT

Create START-HERE.bat at the project root. Its purpose is to provide a simple way for a non-technical user to preview the clean source version. It should:
- Start a lightweight local HTTP server.
- Serve the source/ directory.
- Automatically open the browser.
Prefer a solution that works on a standard Windows installation without requiring a complicated setup. The batch file should clearly indicate if the required local server runtime is unavailable.

9. TWO-VERSION ARCHITECTURE

The final project intentionally contains two versions.

Version 1: Offline (/index.html)
Purpose: double-click, offline, no server, no network, completely self-contained.
Requirements:
- Inline CSS
- Inline JavaScript
- Embedded images
- Embedded fonts
- Embedded required media
- No runtime network requests
- 16 MB or less

Version 2: Editable Source (/source/)
Purpose: development, editing, debugging, WordPress/CMS conversion, easy maintenance.
Requirements:
- Separate HTML
- Separate CSS
- Separate JS
- Local assets
- Clean folder structure

This separation is intentional. Do NOT sacrifice source-code cleanliness simply to make the root file self-contained.

10. MULTI-PAGE WEBSITES

If the target website contains multiple pages:
- Clone the homepage first.
- Identify the other important pages.
- Do not silently omit them.
- List the remaining pages in the final summary.
- If requested, clone additional pages using the same methodology.

11. ASSET RETRIEVAL RULES

Download and locally store all assets required to reproduce the visible experience, including images, SVGs, icons, background images, videos, animation frames, fonts, posters, and decorative graphics.

Do not hotlink the original website. If an asset cannot be retrieved:
- Identify it.
- Explain why it could not be retrieved.
- Use the closest technically appropriate fallback only if necessary.
- Clearly mention the limitation in the final summary.
Do not silently replace important assets.

12. LEGAL / CONTENT BOUNDARY

The purpose of this task is to recreate the layout, structure, styling, interaction patterns, and technical behavior as a development exercise.
- Do not intentionally remove attribution, trademarks, copyright notices, or other ownership information where they are part of the visible original experience.
- Do not represent the cloned website as the original website.
- Keep the implementation focused on the technical reconstruction.

13. FINAL DELIVERY

Build the complete project with the structure shown in 2B, then package everything into website-clone.zip.

FINAL DELIVERY SUMMARY
Include a short summary containing:
- Cloned: what website/page was cloned.
- Architecture: explain that the project contains an offline double-click version and an editable source version.
- Offline version: confirm root index.html is self-contained, CSS is inline, JS is inline, assets are embedded, no runtime network requests are required, and the file size is 16 MB or less.
- Source version: confirm source/index.html, source/css/style.css, source/js/script.js, and source/assets/.
- Animations: briefly list the major animations/interactions reproduced.
- Assets: mention assets successfully retrieved, and assets that could not be retrieved and why.
- Testing: explicitly confirm that root index.html was tested by double-clicking and works offline, and the source version was tested through START-HERE.bat and works through the local server.
- CDN: mention any CDN used in the source version. The root offline version must not depend on the CDN.
- Additional pages: if the website contains multiple pages, list the pages that were identified but not yet cloned.

14. FINAL GOLDEN RULE

Before delivery, ask yourself: If someone places the original website beside my clone and scrolls through both, will the layout, visual hierarchy, assets, responsive behavior, animations, and interactions feel the same?

If the answer is no, continue inspecting, comparing, and correcting. Do not deliver a "close enough" result.

The objective is:
PIXEL-ACCURATE + INTERACTION-ACCURATE + RESPONSIVE + OFFLINE-COMPATIBLE + CLEAN SOURCE

Begin now.