Elementor HTML Double Doctype Fix

Copy

Universal Website HTML Master Instructions (v2: lightweight, single-stylesheet build)
Reusable project brief for WordPress, Elementor, WooCommerce and standalone HTML
How to use
Fill in Section 1, attach the files listed in Section 2, and give this entire document to the website builder. Keep the main rules unchanged unless the new project needs a different choice. Version 2 builds every site as HTML-only pages plus one shared stylesheet with editable design tokens (Sections 9A and 9B), so the site stays light and can be restyled from one place. Bracketed fields are inputs, not text to publish. This document applies to any brand or industry; no previous website's business details should be carried into a new project.
1. Project details to provide first
Business and audience
Brand/display name: [ ]
Legal business name, if different and confirmed: [ ]
Website domain or staging URL: [ ]
Business type and actual products/services: [ ]
Products, services or topics explicitly excluded: [ ]
Target country/countries: [ ]
Target cities/service areas, if genuinely supported: [ ]
Language and local spelling convention: [ ]
Currency and whether displayed prices include tax: [ ]
Confirmed business location/address: [ ]
Public contact email: [ ]
Quick-response email, if different: [ ]
WhatsApp number including country code: [ ]
Telephone visibility: [show number / show WhatsApp label only / no phone]
Social profile URLs: [ ]
Actual operating hours, delivery coverage and purchase policies: [ ]
Verified trust facts and evidence supplied: [ ]
Scope and delivery
New site or update to an existing website: [ ]
Required pages, with page type and preferred slug: [ ]
Required languages/country variants: [ ]
Delivery mode: [downloadable HTML files / install in WordPress / hosted site]
Platform/theme/builder and available versions: [ ]
Default implementation: [Elementor HTML fragments / complete standalone HTML]
Content/container width: [default 1400px unless specified; set once as a CSS token]
Container alignment: [all containers the same full width and left-aligned by default; nothing narrower and centred unless approved]
CSS delivery: [one global stylesheet loaded as a cached file by a small plugin (default) / pasted into theme Custom CSS]
Design tokens to expose for later editing: [colours, fonts, container width, button size, corner radius]
Blog posts: [post-template plugin (default) / theme default]
Header/footer: [shared files / existing theme header and footer / custom]
Products/packages: [my own widgets / supplied shortcode / custom implementation]
Blog grid: [my own widget / supplied shortcode / custom implementation]
Page split locations: [products, blog, pricing, other]
Review stage: [homepage plus one representative page first / complete project]
Required final outputs: [HTML, schema, metadata, settings, URLs, categories, plugin, images ZIP]
Design
Reference website URL(s): [ ]
Reference screenshots and what each screenshot demonstrates: [ ]
What to preserve: [structure / colours / typography / animation / selected sections]
What to change: [ ]
Colour palette with names and HEX values: [ ]
Which palette wins if theme export, screenshot and reference disagree: [ ]
Heading font, weights and sizes: [ ]
Body font, weights and sizes: [ ]
Secondary-language font, if needed: [ ]
Logo, icon and light/dark logo versions: [ ]
Corner style: [rounded / square / specific design]
Focus-word style in headings: [gradient text, no underline, same font by default]
CTA section: [button size, one row, optional text line below]
Shadows/glows: [minimal by default]
Hover, scroll and carousel preferences: [ ]
Testimonials: [omit by default / use attached genuine reviews]
Products, packages and forms
Product names, IDs, variation IDs and SKUs: [ ]
Approved prices, currencies, sale prices and sale rules: [ ]
Package-to-product/variation mapping: [ ]
Checkout flow: 

Required customer fields for an order: [ ]
Payment and fulfilment information actually confirmed: [ ]
Contact form recipient: [current WordPress administrator email / specified address]
Contact form fields: [ ]
Existing form/mail/checkout plugins to reuse: [ ]
Url rules
Information page format: [/page-slug/]
Product category base: [default collection]
Post/guide category base: [default category]
Product URL base: [use supplied site's configured product base]
Shop page slug: [default shop, if WooCommerce is used]
Existing URL/taxonomy mapping that must be preserved: [ ]
Domain migration only, or migration to a subdirectory too: [ ]
Content and seo
Keyword file and target market: [ ]
Excluded brand/competitor keywords: [ ]
Approved internal-link inventory/sitemap: [ ]
Existing content/XML/CSV to preserve or refresh: [ ]
Desired writing perspective: [third-person by default; approved exceptions here]
Any page-specific word counts, FAQ counts or link limits: [ ]
Confirmed authors/expertise/proof available: [ ]
SEO plugin and field mapping, if import is required: [ ]
Index/noindex decisions already agreed: [ ]
Publishing/import/scheduling instructions, only if requested: [ ]
2. Files and references to attach
Provide whichever of these exist. Mark missing items rather than pretending they were supplied.
Current website ZIP/source files, or the latest generated HTML package.
Reference URL and full-page screenshots for the homepage and each distinct page type.
Brand/logo files, site icon, palette screenshot, font names and approved style guide.
Theme settings JSON/XTS export and Elementor global colour/font settings, if applicable.
Keyword CSV/XLSX, with country, date and metric source when available.
Content-writing instructions and approved business information.
Product export CSV: IDs, variation IDs, attributes, SKUs, prices, currency, categories and descriptions.
WordPress XML/export if existing content, dates, categories or post IDs must be preserved.
Media URL CSV and/or image folder with semantic filenames; indicate featured versus gallery images.
Approved page/product/post URL list and existing category names/slugs.
Genuine reviews with permission to use names, locations, photos and quotations.
Delivery, returns, refund, privacy and terms information appropriate to the actual business.
Existing shortcodes and plugin ZIPs that the site needs to use. Never request passwords in the brief or embed secrets in delivered files.
3. Working rules and priorities
Build the requested website, not just a plan or a partial demonstration. Keep a checklist of every requested page, feature and output. Explicit instructions for this project take priority over the generic defaults below. The latest approved correction takes priority over an earlier conflicting preference. Record material assumptions and carry approved corrections across related pages.
Read the supplied files before writing or changing the site. Inspect CSV headers and JSON structure rather than guessing their field meanings. Keep IDs, variants, SKUs, media paths and category slugs traceable to the inputs. Do not silently omit pages or replace a complete requested project with a few samples.
Ask only for a missing detail that materially blocks accurate work. Continue independent work while a detail is unresolved. Do not repeatedly ask for approval already given. For download-only work, deliver the files without publishing a live website. Keep live installation, publication and message/email sending within the user's requested scope.
Do not mix businesses. Never reuse another project's contact details, prices, currency, claims, images, product IDs or policy terms. Do not add services the business does not provide. Do not fabricate missing facts.
4. Analyse the reference before building
Load the actual reference when accessible and wait for images/fonts to settle. Scroll through the entire homepage and each distinct page type. Inspect desktop and mobile behaviour where tools permit. Take internal screenshots as needed to understand the layout.
Record section order, grid spans, image positions, container widths, spacing, heading sizes, text alignment, colours, circles, badges, tabs, accordions, sticky elements, hover changes and animations. Inspect dropdowns and navigation as well as the first screen. Distinguish the homepage, category, service, product, blog and helpful-page structures.
Preserve the supplied visual direction when the request is to reproduce it. Adapt it to this business with original content and authorised imagery. Do not substitute a generic design because only the hero was inspected. Do not copy competitor wording, identities, reviews or proof. If a URL or screenshot cannot be opened, state that limitation and use the available evidence; do not claim it was viewed.
If a review stage is requested, first supply the homepage and one representative page. Apply the accepted corrections consistently to the complete site, including any special page types.
5. Keyword research, search intent and architecture
Start with the actual business, audience and target country. Clean the keyword file: remove empty rows, duplicates and metric values accidentally parsed as queries. Preserve the original query and supplied metrics for auditability. Separate the business's own brand searches from generic searches. Exclude unrelated brands and competitor navigation unless a legitimate, approved comparison page is in scope.
Classify queries as transactional, commercial investigation, informational, local or navigational. Group close variants by intent and topic. Assign each cluster to the correct page type instead of forcing every keyword into the homepage. Distinguish an informational landing page from a product category archive, product detail page and guide category.
Research the current search results for the target country when research access is available. Review representative high-ranking pages, real user questions, recurring subtopics, relevant entities and missing information. Learn the searcher's needs without copying wording or cloning competitor articles. Use authoritative primary sources for technical, platform, regulatory or specialist claims.
If a tool does not provide search volume, difficulty or CPC, do not invent those metrics. Label estimates and source/date information. If current SERP access is unavailable, clearly distinguish analysis of the supplied keyword file from live keyword research.
Build a topical map and URL plan before drafting. For each planned URL record:
Page name, type, path and target market.
Primary query, secondary variants and search intent.
Related entities, attributes, buyer questions and useful subtopics.
Product/post category name, slug and archive path where relevant.
Existing related URL and cannibalisation decision.
Planned internal links, sources and missing business facts.
Check existing pages before creating another URL for the same intent. Recommend CREATE, REFRESH EXISTING, MERGE, REDIRECT or KEEP SEPARATE as appropriate. Do not execute destructive URL/content changes without the requested scope. Avoid thin city pages that merely swap location names.
Produce KEYWORD-MAP.csv and a short research summary. Include excluded, irrelevant and unused terms with reasons in an editorial file, never as a keyword dump on the live page. Cover relevant terms naturally; no fixed density, arbitrary repeat count or forced exact-match phrasing. Use semantic terms and entities, not a fabricated list of 'LSI keywords'.
6. Universal content-writing rules
Write original, useful, business-specific content. Use a friendly, confident and clear voice. Default to third-person brand descriptions unless the project approves a direct reader-facing or first-person brand voice. Never imply personal experience, testing or specialist credentials that were not supplied.
Aim for roughly fifth-grade readability where the subject permits. Prefer familiar words and active voice. Most sentences should be under about 18 words; use longer sentences when needed for accuracy. Avoid a mechanical rhythm. As an editing target, keep passive voice low, around 8% or less, and use natural transitions throughout, roughly 30% of sentences when they fit. Readability and meaning take priority over chasing a score.
Use clear paragraphs under relevant headings. For long-form articles, substantial paragraphs of around 50 words or more can be appropriate; do not pad short answers or force this length onto hero copy, cards, steps, notices or captions. Keep content under one subheading to roughly 300 words before considering another useful subheading.
Use one H1 for the visible page title, followed by H2 and H3 only. Do not add H4-H6. When WordPress supplies the H1 from the page/post title, do not repeat it inside the imported body. Choose heading levels for meaning, not font size.
Use the primary query naturally in the title/H1, opening copy and an appropriate subheading. Use related language throughout and revisit the main subject in the ending when useful. Do not stuff keywords into every heading, alt text, FAQ or paragraph. Use correct spelling in visible text rather than deliberately reproducing search-query typos.
Use bullets, steps and tables when they improve understanding. Bold an entity or phrase only when it is genuinely important to that sentence, not to decorate every keyword. Keep product comparison tables factual and comparable. Avoid unnecessary em dashes, filler openings, exaggerated adjectives, repetitive CTAs and generic claims that any business could make.
Match local spelling, units, currency and terminology to the target market. Add actual local value such as confirmed delivery coverage, climate context or relevant buying considerations. Do not imply an office or branch in a city just because the business serves customers there.
Every factual claim should be treated as common knowledge, supplied business information, sourced specialist information, time-sensitive information, a sensitive claim or unsupported information. Verify changing and specialist facts; remove unsupported claims. Dates, statistics, eligibility rules and product capabilities require suitable sourcing. Keep a source log and research date.
Use evidence of experience and expertise only when real. Never invent star ratings, testimonials, customer names, sales figures, years in business, certifications, success rates, guarantees, delivery times, stock or prices. Omit a testimonial section unless genuine material is provided. If a preview explicitly needs sample content, mark it visibly as a placeholder and keep it out of review/rating schema.
For sensitive health, safety, legal or financial material, research authoritative sources and add a concise professional-advice qualification where it helps readers understand the limits. Do not promise a ranking position or write to manipulate an AI-detection score.
7. Content defaults by page type
Use these as starting defaults, not padding targets. A specific brief, reference structure and reader need can change them.
Homepage
Clear brand positioning, main offer, categories/services, real benefits, buying process, useful trust details, relevant supporting content, FAQ and a final CTA. Keep it distinct from inner pages. Include every approved main category/service and no unrelated ones.
Service page
Usually 800-1,200 words. Hero and CTA, problem/context, what is included, benefits, process, use cases or options, prices/packages if supplied, genuine proof if available, 3-5 relevant FAQs and final CTA. Differentiate related service pages with their actual deliverables and buyer questions.
Product page
Usually 600-1,000 words overall; a standalone long description should generally be at least 800 words when that is the requested format. Include a short description with 8-10 useful bullets, specification/benefit detail, suitability, use/care information, what is included and relevant purchase questions. Use only supplied prices and attributes. Keep the slug concise, normally no more than 4-5 meaningful words. Default to no more than one contextual editorial internal link in the product description unless the project changes that rule; navigation is separate.
Category/collection page
Introduce the category, provide a product-widget position, explain the selection, show relevant finder cards, include a buyer guide, practical quick facts and a substantial usage/care/selection guide where appropriate. Around 800 words is a useful default for a requested detailed guide, rather than an instruction to make every section long. Add a blog-widget position, category-specific FAQ, related browsing and final CTA. Preserve any approved alternative structure for a special category.
Blog/article, when commissioned
Default to at least 2,000 useful words unless the brief sets another length. Start with a two-paragraph introduction using problem, impact and solution without exaggerated fear. Default to at least five meaningful H2 sections, with two or three H3s where the topic warrants them. Include exactly eight relevant FAQs as H3s under an FAQ H2 if the project uses this article specification. End with two concise concluding paragraphs and a suitable CTA. Default to bullet lists in no more than two article sections unless another format is approved. Keep unused keyword notes outside the published article.
Location page
Provide real local information and a reason for the URL to exist. Do not create a doorway page or a near-duplicate location variant. Do not invent a local address, customer or branch.
Helpful pages
About, Contact, FAQs, Delivery/Shipping, Returns/Refunds, Privacy and Terms as appropriate. Use actual business operations. Separate guarantees, refunds, replacements, refill policies and statutory obligations rather than assuming they are interchangeable. Mark missing policy facts for review instead of importing terms from another business.
Content refresh
Preserve the existing URL and search intent unless a change is specifically approved. Improve accuracy, coverage and clarity with fresh original wording. Do not silently remove existing posts, products or categories.
8. Page design and layout
Use the approved palette and fonts consistently. Define named colour tokens for primary, accent, ink, muted text, light surface, dark surface, border and white. If an extra colour is necessary, list its name and HEX value in the settings document. Do not switch palettes or fonts between pages unintentionally.
Keep the default content width at 1400px unless the project specifies another value. Use consistent horizontal gutters and responsive spacing. Make the site look like a professional page-builder website with restrained borders and shadows. Avoid unrequested glows, clipped corners and decorative effects. Preserve circles, textures or badges that belong to the approved reference.
Use one container width everywhere, defined once as a CSS token (for example --w). Do not create narrower centred boxes for article text, FAQs or hero text. Every container takes the full content width and starts at the left edge of the page frame. Only a line-length limit on a short lead paragraph is acceptable. Never set widths in inline style attributes.
Focus words in headings (the highlighted italic words) use a gradient text fill taken from the palette, with no underline and the same font as the design. Apply the style only to em inside H1-H3, never to ordinary emphasis in body text. On a coloured or gradient panel, such as a CTA box, use white or a light gradient so the words stay readable.
In a CTA section keep the buttons medium size (about 12px by 26px padding and 15px text), place them in one row and put any short text line below them, aligned with the buttons. On phones keep two buttons side by side in one row at a smaller size and let the labels wrap. Do not use full-width oversized buttons.
Every page must be responsive. Three-column grids become two columns and then one. Check that nothing scrolls sideways at 375px, 768px and the desktop width. Inline grid or width overrides are not allowed, because they defeat the responsive rules.
For paired text/image sections, align the two columns and give the image a deliberate height, crop and aspect ratio. Match the visual container heights without stretching the photo or creating an excessively tall card. Use object-fit appropriately. A photograph should not become a long strip just because the text is long. Keep repeated cards in a row consistent and align their bottom actions.
Category card titles and descriptions should be left aligned by default. A second-language label can follow that language's direction. When a pair of cards should share a row, set their grid spans explicitly; do not let a generic last-child rule turn the final card full width. Recheck when new categories are added.
Place section-level actions such as 'Browse all guides' beside the heading on the right at desktop widths. Stack neatly on narrow screens. Use actual archive links for these actions. Avoid large empty areas caused by an unnecessary full-width row.
Ensure dark text on light surfaces and light text on dark surfaces. Accent subtitles must remain readable against their background. Check default, hover, focus, active and disabled states. When a button becomes white on hover, its label and icon must become a readable dark colour. Do not rely on an inherited colour from the surrounding dark section.
Use appropriate contrast for text size; target WCAG AA. Make interactions usable with a keyboard and visible focus. Use real button elements for actions and links for navigation. Accordions need accessible states or native details/summary. Tabs and carousels need clear controls and appropriate labels. Honour reduced-motion preferences. Avoid animations that hide content permanently if JavaScript fails.
9. Clean HTML for Elementor and WordPress
Default deliverable is an Elementor HTML fragment, unless standalone pages are requested. Fragments must not contain doctype, html, head or body wrappers, title/meta tags, external font link tags, style blocks or global body/html resets. Metadata, schema and font/theme setup belong in their own outputs.
Wrap each component in a unique brand-prefixed root class. Scope CSS, variables, selectors and JavaScript to that component. Do not use generic selectors that change the theme, WooCommerce widgets or unrelated HTML. A shared header/footer can have its own scoped root. Avoid duplicate main landmarks when the theme already provides one.
Use semantic section/article/nav elements where appropriate. Keep ID attributes unique in the assembled page. Give meaningful images contextual alt text; decorative images should use empty alt text. Give an image-like background an accessible description only when it conveys meaning.
Do not import fonts inside each fragment when the user will configure them in the theme. Give a font-family/weight mapping in the settings guide. Preserve the same typography across all page parts.
Each installation fragment must be independently closed and valid. Never depend on opening a div in one Elementor widget and closing it in another. Components should work in the stated widget order. Do not put a style block in any fragment. All CSS comes from the one global stylesheet described in Section 9A.
Keep technical implementation notes out of the customer-facing layout. Use comments and installation documents for widget placement. Do not publish instructions such as 'add your products here' inside a customer-facing empty box.
9A. Lightweight and customisable build: HTML-only pages and one global stylesheet
Why: a style block copied into every page is downloaded again with every page, makes pages several times larger, and drifts out of sync when one copy is fixed. One shared stylesheet is cached by the browser, is edited in one place and keeps every page identical.
Rules:
1. Page files contain HTML only (plus, if needed, one small scoped script). No style blocks and no per-page CSS.
2. All CSS lives in one file named [brand]-global.css, scoped to the brand root class, plus any named theme wrappers used for theme-level effects. Deliver it in Styles/.
3. Load it as a separate cached file, enqueued by the small plugin or by the theme's custom-CSS file option. Pasting it into Customizer Additional CSS or the theme's Custom CSS also works, but the theme prints that CSS inline in the head of every page, so the browser cannot cache it. Use that route only when no plugin is wanted. Never load the stylesheet twice.
4. Design tokens: define colours, gradient, container width and corner radius as CSS custom properties on the root class at the top of the stylesheet (for example --bg, --surf, --ink, --mut, --bd, --pur, --grad, --w). A rebrand, palette change or width change is then an edit of a few lines. Document the tokens in README.txt and TOKENS.txt.
5. Give every repeated pattern a class (cards, grids, buttons, section heads, CTA, FAQ, article text) instead of an inline style. Use modifier classes such as .g2, .g4, .one, .sp and .tight for variations. Inline styles override the stylesheet and its media queries, so they break responsiveness and customisation. Allow no inline style by default, and only a rare one-off with a stated reason.
6. Organise the stylesheet in labelled sections: theme-level effects, base and components, layout and width, focus words, CTA, FAQ and article text, mobile, post template. Remove exact duplicate rules and keep the order so later rules override earlier ones as intended.
7. Scope rules so they cannot leak. For example, style article headings with a direct-child selector such as .art>h3, so card headings nested inside the article are unaffected. Reconcile two rules for the same selector in the one file instead of keeping both.
8. When merging existing per-page CSS, first build a lossless union of all rules. Render every page before and after the merge and compare them pixel for pixel, ignoring video loading spinners. Investigate every difference. The usual cause is a rule written for one page type leaking onto another. Only after the merge matches may the intended design changes be applied.
9. Do not nest :has() inside :has(). It is invalid and the browser silently drops the whole rule. Check browser support for modern selectors and give important layouts a fallback.
10. Keep animation scripts small and scoped to the root class. Content must stay visible if JavaScript fails, and reduced-motion preferences must be honoured. When many pages use the same script, prefer one shared script file over a copy in every page.
11. To change a style later, edit the global file once. To change content, edit that page's HTML only. State this in README.txt, with a list of the token names and where each main class is used.
9B. Blog posts in the same design
CSS cannot read a post's SEO meta description. A post hero that shows the post title as the H1 and the meta description as the subtitle therefore needs a small plugin that prints markup only. The plugin must:
- run only on single posts, in the main query and the loop, once per request;
- print a hero with a breadcrumb, category tag, the H1 from the post title (the last two words as focus words), the lead text from the meta description, and the date and reading time;
- take the description from the SEO plugin field first (Yoast, Rank Math, SEOPress, AIOSEO), then the excerpt, then the first words of the content;
- print the post content inside the article container, and then a related-guides section (same category, three cards), with no CTA section unless the project asks for one;
- add a body class so the global stylesheet can hide the theme's own title banner and widen the theme container;
- load the global stylesheet file itself, and offer filters to switch that off, to hide the related section and to change the number of focus words.
Editors write normal post content with no classes. The article-text rules in the global stylesheet style headings, links, lists, quotes, tables, images and inline code. Keep one H1 per page: the plugin hero is the H1, so the theme title must be hidden or switched off in the theme settings, not repeated. Also switch off the theme's own related-posts block to avoid duplicates. Name the theme-specific selectors used (for example .page-title for Woodmart) and say in the README which of them were tested on a live site.
10. Split pages at user-managed widgets
When the owner will add product and blog widgets, supply:
01-before-products.html
02-after-products-before-blog.html
03-after-blog.html
complete-review.html
INSTALL.txt
Installation order: part 01, the owner's product grid/carousel, part 02, the owner's blog grid/carousel, part 03. Preserve the surrounding design and section headings. Each part is HTML only, with no style block, and has independent valid structure. The shared global stylesheet styles all parts, so the order of the parts cannot undo an earlier fix. Add another numbered part if pricing or a second product area also needs an owner-managed widget.
Do not duplicate products or blog cards inside the HTML when the owner is supplying them. Keep full-review files clearly marked as previews so they are not installed in addition to the split parts. Remove superseded installation filenames from the final package and update all instructions.
11. Internal links, archives and migration
Use root-relative paths for same-site links and media, for example: /service-name/ /collection/product-category-slug/ /category/guide-category-slug/ /wp-content/uploads/YYYY/MM/image-name.avif
Do not hardcode the current domain in these links. Preserve the actual upload date and filename supplied in the media CSV. Root-relative paths support a domain change when the same site paths and media are migrated; they do not by themselves solve moving WordPress into a different subdirectory. For that case, resolve paths through WordPress at runtime or provide the appropriate migration mapping.
Keep informational page routes separate from product and post category archives. Unless changed in the brief, product categories use the base 'collection' and post categories use 'category'. Provide exact names, slugs, hierarchy and paths in CATEGORIES-TO-CREATE.txt. Do not add a parent category silently because it can change the resulting path. Explain which permalink bases and shop-page settings must be configured.
Shopping buttons must open the relevant product/category archive or approved checkout action. Guide-category buttons must open the relevant /category/.../ archive. Do not use href='#', fragment URLs or nonfunctional placeholders for ordinary navigation. For on-page guide contents, use accessible scroll buttons with data targets if the brief excludes fragment links. Keep SVG drawing references separate; they are not navigation URLs.
Use descriptive anchors that match the destination and the paragraph's subject. Avoid raw URLs and 'click here'. Keep a paragraph's editorial internal links focused on one destination. Link only to supplied, existing or explicitly planned deliverable URLs; list any route requiring the owner to create an archive or page. Every important page should receive a relevant incoming link. Check menus, footer, cards, breadcrumbs, related browsing, CTA and mobile navigation.
For articles using the special two-link workflow: place one related article link in paragraphs 1-3, and one product or information-page link in the paragraph immediately before FAQs, not in the conclusion. For paired articles, alternate that second destination type between product and page. Apply these counts only when that workflow is selected; do not impose a universal two-link limit on all websites.
Use external references to support a statistic, research finding, specialist statement or definition, not to pad link counts. Prefer primary sources. For an article, normally use no more than 2-4 well-chosen external sources unless the topic requires more. External links opened in a new tab need rel='noopener noreferrer'.
12. Images, logos and media
Create an image manifest mapping filename/key to page, section, alt text, crop/aspect ratio, source and final media path. Use semantic names. Inspect image subjects before assigning them to products. Do not pass a generic stock photo off as proof of a specific product, customer or result.
Use supplied media URLs accurately, matched by filename and intended use. Optimise dimensions and formats without distorting images. Keep text and important subjects within a useful crop. Lazy-load below-the-fold images; load only the main visible hero image eagerly with high fetch priority. Do not give every image high priority.
Download reference images only when they are available and authorised for use. If an image is missing, select an appropriate permitted alternative or generate an original visual when authorised. Do not claim an image was downloaded or reviewed if it was inaccessible. Do not remove third-party ownership marks or required disclosures. Preserve transparency when the requested asset needs it.
If illustrative metrics, dashboards or account/specification visuals are requested, make their illustrative status clear. Do not fabricate a genuine customer result, account screenshot, platform verification or compliance proof. Use verified specifications and avoid invented eligibility claims.
If requested, deliver a separate image ZIP organised by page/purpose, with semantic filenames and an image-path/alt-text manifest. Include only the assets actually supplied or created, and distinguish rendered assets from spares. A source domain must not be needed for migrated local media to work.
13. Woocommerce products, packages and checkout
Use the exact product and variation IDs supplied. Never guess an ID or bind a button only by its visible package name. Maintain a mapping of page, package, product ID, variation ID, required attributes, SKU, price, currency and destination.
Show approved prices in the requested visible position, not only in schema or CSV. Keep page prices, product CSV, shortcode output and schema consistent. Distinguish follower/subscriber counts, quantities, size variants and other specifications accurately. Apply a regular-price uplift or currency conversion only when explicitly instructed; record the rule and rounding. Never invent a sale price or stock level.
If CSV updates are requested, preserve the importer format and existing IDs. Update titles, SKUs, short descriptions, long descriptions, featured image, gallery and categories only within the authorised scope. Preserve variation relationships and required attributes. Verify prices and image mapping for every relevant item.
Implement the requested purchase flow: product page, cart or add-to-cart then checkout. A variable product must resolve the correct variation and required attributes. Do not claim a static link handles every WooCommerce configuration. Use a small plugin or supported integration if necessary, and verify current official documentation before implementation.
Test empty-cart and existing-cart behaviour, package changes, repeated clicks, required order fields, add-to-cart errors and checkout redirection. Keep customer data requirements appropriate to the purchase. Explain any live test not performed. Do not submit real payments or send order messages without the requested authorisation.
Indexation is separate from publication and purchase functionality. Follow the agreed SEO architecture: informational landing pages may be indexed while transaction-only product/shop pages remain published but noindexed if that is the chosen strategy. Do not apply this to every store automatically; valuable product/category pages may deserve indexing. Avoid conflicting canonical, noindex, robots and sitemap settings. Do not block crawling of a page while expecting crawlers to read its noindex instruction.
14. Contact forms and small plugins
A decorative HTML form alone cannot send mail. Provide the required WordPress integration or plugin if email sending is requested. If the recipient is the website administrator, read the current administrator email from WordPress settings rather than hardcoding a previous domain's mailbox.
Validate and sanitise on the server, use appropriate request protections, limit abuse, and handle errors safely. Never expose secrets or stack traces. Give clear submitting, success and failure states, accessible labels and a visible fallback contact route. Do not collect unnecessary information or store enquiries without a reason disclosed in the privacy information.
Use a suitable site-domain sender and a validated customer Reply-To address. Explain any mail-transport setup needed. Confirming that a mail function accepted a request does not prove inbox delivery; perform a live administrator-inbox test when available and authorised. Do not send an unsolicited test email during an offline build.
Deliver an installable plugin ZIP, source, configuration/readme and any required shortcode. Keep scripts/styles scoped. Avoid duplicate forms or duplicate schema when other plugins already provide them. Keep the solution as small as the actual function requires.
15. Metadata, schema and theme settings
Provide per-page metadata: page name/type, focus keyword, title, meta description, slug/path, canonical path, social title/description and social image path. Make titles and descriptions unique and accurate. Use the format 'Page Title %%sep%% %%sitename%%' when the SEO plugin uses those tokens; do not append the brand manually as well.
Aim for a concise rendered title, typically around 50-60 characters, and a description around 155-160 characters. Inspect the final title after token expansion. These are editorial targets, not guarantees of how a search engine will display them. Include a useful number or persuasive word only when factual and relevant; avoid clickbait.
Select schema that matches the page: Organization, WebSite, BreadcrumbList, CollectionPage, Product, Service, Article/BlogPosting, Person, LocalBusiness or FAQPage where appropriate. Mark up only visible, supported facts. Do not invent ratings, reviews, prices, availability, authors, addresses or qualifications. Do not duplicate product/schema output already owned by WooCommerce or an SEO plugin. Check current eligibility rules before promising rich-result appearance.
Keep delivered canonical paths domain-independent, but resolve canonical, social and schema URLs into correct absolute production URLs at runtime using the current site URL. Do not emit relative canonical tags as the final production implementation. Include an installation method for domain-independent schema templates, with stable entity IDs and no duplicate graphs.
Provide theme.json when useful and a theme-specific settings export only in the format actually supported by the supplied theme. A generic WordPress theme.json and a Woodmart/XTS export are different formats. Preserve unrelated settings in an existing export. Document changed colour/font keys and provide a named Elementor palette. Do not claim a file is import-compatible without checking its structure.
16. Bulk content and WordPress imports, when requested
Preserve existing posts, IDs, slugs, dates, category relationships and media unless the task explicitly changes them. For new-only imports, include only the requested new items. Do not silently delete, merge or rename content.
Put article titles in the importer title field, without a second H1 in the body. Map categories to the actual taxonomy export. Include the requested metadata/social/canonical/schema fields using the site's importer and SEO-plugin conventions. Preserve real sources and researched stats; player/product comparisons need current, like-for-like tables where relevant.
Follow the requested number of items, publication statuses, dates, timezone and cadence exactly. Verify the count of published versus scheduled items and avoid putting every historical article on a single date. Check that each article has the required relevant incoming and outgoing internal links. Include an import guide and explicit limitations; a well-formed file is not proof that a live import succeeded.
17. Optional growth outputs — only when included in the scope
For a wider SEO project, add a topical roadmap, genuine local citation opportunities, content gaps, useful linkable assets and a plan to refresh changing facts. Do not guarantee rankings or manufacture reviews/backlinks.
If social packs are requested, adapt the same factual topic to each channel rather than posting identical copy everywhere. Use the approved target market and a relevant page/product referral link. Supply a title for Pinterest, suitable concise X copy, useful Facebook/Instagram captions and professional LinkedIn copy where relevant. Use only necessary platform-appropriate hashtags. Provide a reusable image brief and a schedule/team allocation if requested. These tasks are separate deliverables, not reasons to delay the requested website files.
18. Quality checks before delivery
Completeness
count every requested page, HTML part, category, image, package and output. All requested categories must be represented in the homepage and relevant navigation. Keep excluded topics out.
Content
check brand, target country, contacts, currency, facts, spelling, originality, keyword intent, unsupported claims and irrelevant copied information. Verify that no internal editorial notes or fake testimonials appear in the public output.
HTML
check balanced independently closed fragments, semantic structure, unique IDs, one intended H1, H2/H3 hierarchy and no unwanted wrappers/global resets. Validate JSON, CSV/XML where supplied, and JavaScript syntax.
Links
verify every navigation destination against the delivered URL inventory. Ensure archive bases/slugs match the category text file. Check root-relative media paths against the supplied manifest. Remove dummy # links. Ensure all on-page scroll buttons point to existing targets. Check 404s and redirects on the live site when access is available.
Visuals
inspect full pages at desktop, tablet and mobile widths when browser QA is available. Check image crops, equal card heights, text/image balance, no overflow, no blank half rows, right-aligned heading buttons and readable subtitles. Check hover/focus colours for both button labels and icons. Recheck the assembled split-page order with the global stylesheet loaded, because a rule written for one page type can leak onto another.
Interactions
verify menus, accordions, tabs, scroll controls, carousels, reduced motion, form validation, errors, required fields, product/variation mapping and the requested checkout flow. Test meaningful behaviour rather than merely mirroring implementation details.
SEO
check intent, natural keywords, cannibalisation, contextual links, unique metadata, canonicals, indexing choices, visible/schema consistency, image alt text and performance basics. Check legal/sensitive wording against the business facts and applicable current sources.
CSS and performance
confirm that no page contains a style block and that no inline width or grid override is left. Confirm that the stylesheet loads once, as a cached file where possible. Confirm that a merged stylesheet matches the original pages pixel for pixel before any design change. Run computed-style and overflow checks on every page at 375px, 768px and a wide desktop: no horizontal scroll, container width equal to the token, article text and FAQ starting at the container's left edge, focus words with a gradient and no underline, CTA buttons in one row at the agreed size. Check that no selector nests :has() inside :has(). Report page weight before and after.
Packaging
remove obsolete installation parts, temporary files and stale instructions. Confirm ZIP integrity and that it opens. Test plugin/import packaging where possible. State clearly which checks were local and which live WordPress, inbox, checkout or visual checks remain. Never report an unavailable check as passed.
19. Required delivery structure
Use a clearly named package such as Brand-Website.zip, organised as:
Pages/Page-Name/
  01-before-products.html
  02-after-products-before-blog.html
  03-after-blog.html
  complete-review.html
  INSTALL.txt
  metadata.json
  schema.json
For pages without insertion points, use index.html instead of unnecessary split files.
Shared/
  header.html, footer.html and approved brand assets, if requested
SEO/
  metadata.csv, metadata.json, all-page-schema.json
  KEYWORD-MAP.csv, research-summary and source log
Styles/
  [brand]-global.css (the only stylesheet; page files contain no CSS)
  TOKENS.txt (colour, font and width tokens to edit, and what each class does)
Settings/
  theme.json, theme-specific settings export if applicable
  ELEMENTOR-COLOURS.txt, typography mapping and change notes
Plugin/
  post-template plugin ZIP with the global stylesheet in its assets folder (loads the CSS once as a cached file), installable ZIP, source and installation instructions, when needed
Guides/
  image manifest, page-folder index, installation and validation reports
URLs.txt
CATEGORIES-TO-CREATE.txt
README.txt
Provide Images.zip separately when requested. Include per-page or individual files when the owner requests them. Files must have meaningful names. Keep the latest package complete so an old download is not needed to install missing parts.
README must explain the widget order, how the global stylesheet is loaded and edited, the design tokens, font/colour setup, media requirements, category/permalink settings, plugin installation, schema/metadata integration and any live verification still needed. Explain which pages are designed landing pages and which links are actual product/post archives.
Finish with download links and a concise account of what was delivered, what was checked and any material installation dependency. Do not just paste a proposed plan or say the website is complete when requested parts are missing.
it will generate whole website content