Website

Publish llms.txt on your WordPress site: try the SEO plugin first, then a safe snippet

Checks whether your SEO plugin can generate llms.txt and whether its output is good enough. If not, builds a file by hand from the site's real pages, serves it at /llms.txt through a WPCode snippet after approval and verifies it live.

When to use it

Your site runs on WordPress and you want to publish an llms.txt that describes your business correctly, but you do not know whether your SEO plugin already does it or how to serve the file.

What you get

A clear assessment of your SEO plugin's llms.txt feature, or a file built from your real pages, live at /llms.txt after your approval and verified to return 200 as text/plain, plus a rollback path.

Does it change anything in my account?

Only with your approval. The assistant first shows a preview of every change and waits for your go-ahead.

Works with

WordPress, SEO Intelligence

Fill in before sending

[WordPress site][extra facts, or "none"][business name][Page name][today's date]

Publish an accurate llms.txt at /llms.txt on my WordPress site [WordPress site]. Facts about my business that are not on the site but that I confirm are correct: [extra facts, or "none"]. llms.txt is a proposal published at llmstxt.org. It helps AI assistants understand a site correctly, but major providers have not said they use it as a ranking or citation signal. Tell me this once and keep the job small and accurate. 1. Map the current state. Find the site with list_wordpress_sites, find the SEO plugin and its version with wordpress_list_plugins, and read the plugin's site-level settings with wordpress_seo. Check [WordPress site]/llms.txt with site_read_url: show the status code and the content if there is any. 2. The plugin route. Current versions of Yoast SEO, Rank Math and All in One SEO include a feature that generates llms.txt. Read the plugin's settings record with wordpress_option and write=false (for Yoast the option name is `wpseo`) and find out whether the llms.txt feature is on. If you are not sure of the key name, do not guess, tell me which screen in the plugin's panel to check. If the feature is on, judge its output: does it only list recent blog posts, are the service and contact pages there, are the descriptions correct. If it is good enough, stop here and give me a short assessment. 3. Build it by hand (no plugin feature, or its output is not good enough). List the pages with wordpress_list_posts, type='page' and status='publish', then the 10 most important posts. Read the homepage, the service or product pages, about, contact and pricing pages with site_read_url and text=true; if the reply says truncated is true, read again with max_bytes=1000000. Write the draft like this: first line `# [business name]`, below it a one or two sentence summary starting with `>`, a short core facts paragraph, then `## Services`, `## FAQ` and `## Company` sections with each line as `- [Page name](full URL): one-sentence description`, and finally legal pages and the blog under `## Optional`. Use only facts that are on the site or that I gave you; if prices, opening hours, ratings, customer counts or certificates are not on the site, leave them out. End the file with `Last updated: [today's date]`. Run seo_content_lint on the text and fix any flagged phrases. Test every link with site_read_url and max_bytes=0. 4. Preview. Show the full file, the source page for each fact and the publishing route. The route is a PHP snippet created with wordpress_snippet, location 'everywhere'. On the `init` hook, when the request path is exactly `/llms.txt`, the code sends `Content-Type: text/plain; charset=utf-8`, prints the text and exits, and it touches no other request. Show the code in the preview too. If the plugin's own llms.txt feature is on, tell me to switch it off first so the two sources do not clash. Wait for my approval. 5. Apply after approval. Create the snippet with wordpress_snippet action='create'. It is created inactive; turn it on with action='toggle' and active=true. If activation returns an error the snippet stays off, so show me the error. If a cache plugin is active, clear the cache with wordpress_purge_cache. 6. Verify. Read /llms.txt with site_read_url: the status must be 200, the content-type text/plain and the content the text I approved. If the URL returns 404, the web server is not passing .txt requests to WordPress at all. In that case turn the snippet off and explain how to upload the file to the site root through the hosting panel or FTP. Also check with site_read_url that the homepage still returns 200. Finish with the rollback path: the snippet's ID and how to turn it off with wordpress_snippet. Also remind me that a new service page, a price change or an address change means the text in the snippet must be updated.

Publish an accurate llms.txt at /llms.txt on my WordPress site [WordPress site]. Facts about my business that are not on the site but that I confirm are correct: [extra facts, or "none"].

llms.txt is a proposal published at llmstxt.org. It helps AI assistants understand a site correctly, but major providers have not said they use it as a ranking or citation signal. Tell me this once and keep the job small and accurate.

1. Map the current state. Find the site with list_wordpress_sites, find the SEO plugin and its version with wordpress_list_plugins, and read the plugin's site-level settings with wordpress_seo. Check [WordPress site]/llms.txt with site_read_url: show the status code and the content if there is any.
2. The plugin route. Current versions of Yoast SEO, Rank Math and All in One SEO include a feature that generates llms.txt. Read the plugin's settings record with wordpress_option and write=false (for Yoast the option name is `wpseo`) and find out whether the llms.txt feature is on. If you are not sure of the key name, do not guess, tell me which screen in the plugin's panel to check. If the feature is on, judge its output: does it only list recent blog posts, are the service and contact pages there, are the descriptions correct. If it is good enough, stop here and give me a short assessment.
3. Build it by hand (no plugin feature, or its output is not good enough). List the pages with wordpress_list_posts, type='page' and status='publish', then the 10 most important posts. Read the homepage, the service or product pages, about, contact and pricing pages with site_read_url and text=true; if the reply says truncated is true, read again with max_bytes=1000000. Write the draft like this: first line `# [business name]`, below it a one or two sentence summary starting with `>`, a short core facts paragraph, then `## Services`, `## FAQ` and `## Company` sections with each line as `- [Page name](full URL): one-sentence description`, and finally legal pages and the blog under `## Optional`. Use only facts that are on the site or that I gave you; if prices, opening hours, ratings, customer counts or certificates are not on the site, leave them out. End the file with `Last updated: [today's date]`. Run seo_content_lint on the text and fix any flagged phrases. Test every link with site_read_url and max_bytes=0.
4. Preview. Show the full file, the source page for each fact and the publishing route. The route is a PHP snippet created with wordpress_snippet, location 'everywhere'. On the `init` hook, when the request path is exactly `/llms.txt`, the code sends `Content-Type: text/plain; charset=utf-8`, prints the text and exits, and it touches no other request. Show the code in the preview too. If the plugin's own llms.txt feature is on, tell me to switch it off first so the two sources do not clash. Wait for my approval.
5. Apply after approval. Create the snippet with wordpress_snippet action='create'. It is created inactive; turn it on with action='toggle' and active=true. If activation returns an error the snippet stays off, so show me the error. If a cache plugin is active, clear the cache with wordpress_purge_cache.
6. Verify. Read /llms.txt with site_read_url: the status must be 200, the content-type text/plain and the content the text I approved. If the URL returns 404, the web server is not passing .txt requests to WordPress at all. In that case turn the snippet off and explain how to upload the file to the site root through the hosting panel or FTP. Also check with site_read_url that the homepage still returns 200.

Finish with the rollback path: the snippet's ID and how to turn it off with wordpress_snippet. Also remind me that a new service page, a price change or an address change means the text in the snippet must be updated.

Open in Claude Open in ChatGPT Discuss in the forum

Example result

An example of the output this prompt produces. Its structure comes from the tools' real output; numbers and names are fictional.

Example output (based on a fictional site, not real customer data)

Current state. The site runs Yoast SEO and its llms.txt feature is on. /llms.txt returns 200, but the file only lists the 10 latest blog posts. There are no service pages, no contact page and no summary of what the business does. So a hand-built file was proposed, and you were asked to switch off the Yoast llms.txt feature first.

Fact	Source page
Home and office moves in Leeds	/about/
Free survey via WhatsApp	/contact/
Lift-assisted moving service	/services/lift-moving/

There are no prices on the site, so none were written. seo_content_lint flagged "leading" and "most trusted", and both were removed.

After your approval snippet 412 was created and activated, and the cache was cleared.

Check	Result
/llms.txt status code	200
content-type	text/plain; charset=utf-8
Content matches the approved text	Yes
Homepage	200

To roll back: wordpress_snippet action='toggle', snippet_id=412, active=false.

More prompts

WebsiteChanges after your approvalLive demo

Build an editorial expert site with a guides section and author schema

Has your assistant build an expert's site with a magazine-cover home page, long-form guides and an author profile. Serif typography, Article and Person schema and dated, sourced articles produce a publication people read and AI answers can cite.

When to use itWhen you are a consultant, specialist or one-person knowledge business and want your site to read like a publication that shows your expertise through writing, not like a brochure.

Build an editorial-style expert site for me on my Opus Growth hosting server [server name]. Me: [full name], [specialism, e.g. export consultant], [area I serve, or "online"]. Services: [services]. Experience: [real experience and the sectors I have worked in; do not invent]. Phone: [phone], email: [email], domain: [domain]. Topics of the first two guides: [topic 1], [topic 2]. If my office receives visitors, its address: [address or "none"].

The site should read like a publication that proves expertise through writing, not like a brochure. The guides sit at the centre of the site, because they are what readers and AI answers quote.

The design direction is editorial:
1. Type: a characterful serif from Fontshare for headings (e.g. Zodiak 700 and 400 italic) and a calm sans for interface and short text (e.g. Author 400 and 600). Article body set in the serif at 19 pixels, line height 1.7, at most 68 characters per line.
2. Colour: cream paper background, dark ink text, a secondary warm grey and one dark accent (e.g. oxblood). The accent appears only on kickers, the drop cap and the pull-quote rules.
3. Grid: 12 columns; an asymmetric 7 to 5 cover on the home page with thin vertical rules between columns. No shadows or rounded corners.
4. Signature element: a masthead with a double rule like a newspaper nameplate (with a thin dateline above), and in articles a large drop cap in the accent colour plus a margin pull quote.
5. Motion: none.

Pages and their schema:
1. index.html (cover): a headline and standfirst whose first paragraph answers "who are you, whom do you help with what", the lead article image and title, a side column with the other article, services and author boxes, a pull quote, and a "how I work" band. WebPage and Person.
2. hizmetler.html: one section per service; the first paragraph says who it is for and when, followed by numbered steps and the written deliverable. A Service per service with the author Person as provider.
3. hakkimda.html: real experience, working principles (no guaranteed outcomes), how the articles are produced and the sourcing policy. ProfilePage with mainEntity Person (jobTitle, knowsAbout, worksFor #org).
4. rehber/index.html: articles newest first, with date and author. CollectionPage and ItemList (numberOfItems).
5. rehber/[article].html: at least 700 words, a first paragraph that answers the question directly, an H2 hierarchy, a table with thead and th scope where it helps, at least one pull quote, two to four internal links and sources at the end. At the top an author link and the publication and last-updated dates in <time>. Article (headline, image, datePublished, dateModified, author via @id to the Person, publisher #org). If you use example figures, say they are fictional.
6. iletisim.html: ContactPage. 7. kvkk.html (privacy notice) and 404.html.

If the office does not receive visitors, set localBusiness: false in site.config.js; Organization plus Person is enough.

Technical rules. Follow them exactly, because the gates below measure exactly these:

1. Setup. Run scaffold_site as a preview first, show me the file list, and install with confirm=true after I approve. Then read site_design_guide and site_seo_guide in full. Before writing any code, write the direction in _kaynak/ART.md (feel, font pairing, colours with contrast ratios, grid, signature element, motion decision, page list) and show it to me.
2. Strip out JavaScript. No page on this site loads any JavaScript. Remove from every page the cdn.tailwindcss.com script, the tailwind.config line, the GSAP, ScrollTrigger, SplitText, Lenis and Swiper tags and the motion.js, chrome.js and site.config.js script tags; delete assets/chrome.js and assets/motion.js. Keep assets/site.config.js, but only as the brand, contact and seo source for seo-stamp.mjs; it is never loaded in the browser.
3. Menu and footer are static HTML. The <site-nav> and <site-footer> components are drawn by JavaScript, so search and AI crawlers cannot see the menu, the internal links or the contact details. Write the header to _kaynak/ust.inc and the footer (name, address, phone, email, every page link, privacy notice, "Web: Opus Growth") to _kaynak/alt.inc. Use the .inc extension so seo-stamp and html-validate do not treat the fragments as pages. Every page carries the markers  and . Then write a dependency-free Node script with site_write_file at _kaynak/parca-bas.mjs: it stamps both fragments between the markers in every HTML file, adds aria-current="page" to the current page's menu link, and rewrites sitemap.xml using each page's JSON-LD dateModified as lastmod (skipping 404 and noindex pages). Build the mobile menu without JavaScript using <details><summary>Menu</summary>; the desktop and mobile menus are two separate <nav> elements with different aria-labels.
4. Host the fonts yourself. This site uses two families and five files at most; the heading, italic standfirst and body fonts all appear on the first screen, so preload all four. In the demo, preloading only two pushed CLS on a long article to 0.24 and mobile Performance down to 86; preloading all four gave CLS 0 and Performance 99. Download the Fontshare CSS (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap, weight code 401 for italic) with site_fetch to _kaynak/fontshare.css, read it with site_read_file and take only the woff2 URLs of the family you asked for; the service sometimes appends a family you did not request. Download each woff2 with site_fetch into assets/fonts/. Put the @font-face rules (font-display: swap) inside assets/app.css, because design-check.mjs only looks for a custom font in that file. Do not use the default Inter, Roboto, Poppins or Montserrat.
5. Compile Tailwind. assets/app.css becomes the Tailwind source: @tailwind base; @tailwind components; @tailwind utilities; at the top, then @font-face, the focus ring, the skip link, a prefers-reduced-motion rule and your own component classes inside @layer components. Never give a component class the name of a Tailwind utility (list-item, table, grid, container, hidden and so on), because the clash silently breaks the layout after compiling. Write tailwind.config.js at the root (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"], colours and fontFamily). Run "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" with site_run_command and background=true, and wait for it with site_command_status. Every page <head> holds, in this order: a single <link rel="stylesheet" href="/assets/site.css">, then one preload line for every font file used on the first screen (heading, accent and body; as="font" type="font/woff2" crossorigin). Preload lines placed before the stylesheet delay the CSS and lengthen LCP; a first-screen font left without preload swaps late, shifts the page and raises CLS, and <link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. The favicon line is required: without it the browser asks for /favicon.ico, gets a 404, and the console error lowers Best Practices.
6. Images. Download photos with site_fetch using resize and image_format="webp" at several widths (480, 800, 1200 and 1600 for the first-screen image, 480, 800 and 1200 for the rest; quality between 60 and 75, lower for detailed photos). Every <img> has srcset, sizes that match the real layout, width and height (zero CLS) and a meaningful, honest alt text. fetchpriority="high" goes only on the image Lighthouse reports as the LCP element, and that image is not lazy; every other image uses loading="lazy". If the LCP element is text, no image gets fetchpriority. Also prepare assets/img/logo.png, a 1200x630 assets/img/og.jpg and assets/img/favicon.svg.
7. HTML rules (html-validate defaults). <!DOCTYPE html> in upper case; no inline style attribute (including the kit's style="background:var(--brand)", use a class instead); &nbsp; instead of plain spaces in the text of tel: links; a type on every <button>; no trailing whitespace; tables with <thead>, <tbody> and th scope. Links inside paragraphs are underlined; menu, footer, breadcrumb and button links have a touch area of at least 44x44 pixels (min-h-[44px] min-w-[44px]).
8. Structured data. Fill the seo block in site.config.js (siteUrl, description, logo, og image, business type, address fields) and run "node seo-stamp.mjs" with site_run_command; it stamps Organization, WebSite and, where relevant, a LocalBusiness subtype, plus canonical and OG tags. Add page-specific schema by hand: on every page a WebPage node with an @id (or AboutPage, ContactPage, CollectionPage, ProfilePage), datePublished and dateModified, isPartOf #site, about #business or #org, and breadcrumb pointing to a BreadcrumbList; plus a Service per service, Person and ProfilePage for the author, ItemList on the guides index and Article on every guide. Write each node in its OWN <script type="application/ld+json"> block and do not use an @graph wrapper, because seo-check.mjs only reads the top-level @type and misses a BreadcrumbList inside @graph. Link the nodes with @id. Never invent opening hours, coordinates, ratings, reviews, awards, customer counts or certificates; leave unknown fields out.
9. AI access. Write robots.txt: the whole site open, only /_kaynak/ closed; Allow: / for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended and Bingbot; your decision on CCBot with the reason as a comment; the Sitemap line last. Add llms.txt at the root: a correct two-sentence summary of the business, the important pages with one line each, and contact details. Write 404.html (noindex, with the header and footer markers).
10. Writing. Each page has at least 150 words of original text inside <main>, and the first paragraph answers the page's main question directly. Titles are 48 to 60 characters, descriptions 145 to 158, unique on every page. No em dashes or en dashes, no stock slogans, no empty promises. If anything on the site is not real, say clearly that it is fictional.

Gates. After every change, run these with site_run_command in this order and do not move on until each one is clean:
1. node _kaynak/parca-bas.mjs, node seo-stamp.mjs, the Tailwind build (again if you added classes).
2. node seo-check.mjs: 0 errors and 0 warnings. If it warns "gövde kısa" (body too short), add real text, not filler.
3. node design-check.mjs: 0 errors. The only warning may be "Hiç hareket yok" (no motion); it is a deliberate choice for the reading experience, so give the reason in the report.
4. npx --yes html-validate "**/*.html": 0 errors.
5. Look at every page with site_preview at view="mobile" and view="desktop", and check the home page at 360 and 768 pixels as well. Fix any horizontal overflow, cramped heading or touch target smaller than 44 pixels and look again.
6. Measure every page with core_web_vitals at strategy="mobile" and strategy="desktop", then audit the home page and the longest page with seo_audit. Target: on mobile, Accessibility, Best Practices and SEO 100 and Performance at least 95; on desktop all four at least 95. Not a single request may leave the site. If LCP is high, use resources=true to find the file holding it back: usually preload lines placed before the stylesheet, or fetchpriority given to an image that is not the LCP element. If CLS exceeds 0.1, look for a first-screen font that is not preloaded.
Do not call the job done until all of these pass.

After publishing, submit https://[domain]/sitemap.xml with gsc_submit_sitemap and check the home page with gsc_url_inspect. If there is no Search Console property, tell me; do not try to connect one yourself.

WebsiteChanges after your approvalLive demo

Build a heritage family business site with a classic look and modern standards

Has your assistant build a site in the spirit of an old label and shop sign for a producer in its third generation, framed and with a paper texture. The look is old, the build is new: mobile first, JavaScript-free, self-hosted fonts, WebP, Product and HowTo schema.

When to use itWhen you sell a craft passed down through generations, such as Turkish delight, olive oil, cheese or copperware, and want a classic look that carries that history without giving up speed or accessibility.

Build a traditional-looking site for our family business on my Opus Growth hosting server [server name]. Business: [business name], [what we make, e.g. olive oil or Turkish delight], [city], [founding year and generation, only if true]. Products: [for each, name, pack size, short description and the published price, or "no price"]. Production steps: [short list]. How people order: [phone, shop, delivery]. Phone: [phone], email: [email], shop address: [address], domain: [domain]. Family and archive photos: [where they are, or "none"].

The look is old, the build is new. It should feel like an old label, a shop sign or a harvest ledger, yet the pages must open flawlessly on a phone, load no JavaScript and every page must be measured. The old look is never an excuse for poor legibility or contrast.

The design direction is traditional:
1. Type: one classic serif family from Fontshare (e.g. Gambetta 400, 400 italic, 600). Small capitals with font-variant-caps: all-small-caps and wide tracking on the menu, buttons and labels; centred headings.
2. Colour: a paper-tone background, ink-brown text, a secondary brown and one main colour (e.g. olive green), with a second warm colour only on tiny labels. All at least 4.5:1 contrast.
3. Texture: a paper texture for the background as an SVG feTurbulence data URI in the CSS; no extra image file and no extra request.
4. Signature element: an old label frame, a double-ruled box with corner ornaments (border, outline-offset and ::before, ::after), and a small ornament drawn in inline SVG between sections (e.g. an olive sprig), aria-hidden.
5. Layout: centred and narrow; products in framed label cards, one column on mobile.
6. Motion: none.
7. Photos: use the family archive if there is one. Otherwise you may use public domain or openly licensed archive photos, but state the source and licence in the caption and never present them as the family's own.

Pages and their schema:
1. index.html: a framed first screen whose opening paragraph answers "who, makes what, where, sells how", product labels, a family section, how to order. WebPage. Set the most fitting business subtype in site.config.js (e.g. Store or FoodEstablishment).
2. urunler.html: each product in its own label card with name, pack size, description and published price. CollectionPage and a Product per item (brand, manufacturer #business, offers with price, priceCurrency, availability). Never write a price I have not given you; with no price, leave offers out entirely.
3. hikayemiz.html: the real story, generation by generation. AboutPage.
4. uretim.html: the steps from harvest or raw material to the pack, the official grade definition of the product and the regulation it rests on (e.g. the Turkish Food Codex). WebPage and HowTo.
5. sss.html: six real questions on ordering, delivery and storage. FAQPage.
6. iletisim.html: order phone, shop address, a map link; leave hours out if they change with the season. ContactPage.
7. kvkk.html (privacy notice) and 404.html.

Technical rules. Follow them exactly, because the gates below measure exactly these:

1. Setup. Run scaffold_site as a preview first, show me the file list, and install with confirm=true after I approve. Then read site_design_guide and site_seo_guide in full. Before writing any code, write the direction in _kaynak/ART.md (feel, font pairing, colours with contrast ratios, grid, signature element, motion decision, page list) and show it to me.
2. Strip out JavaScript. No page on this site loads any JavaScript. Remove from every page the cdn.tailwindcss.com script, the tailwind.config line, the GSAP, ScrollTrigger, SplitText, Lenis and Swiper tags and the motion.js, chrome.js and site.config.js script tags; delete assets/chrome.js and assets/motion.js. Keep assets/site.config.js, but only as the brand, contact and seo source for seo-stamp.mjs; it is never loaded in the browser.
3. Menu and footer are static HTML. The <site-nav> and <site-footer> components are drawn by JavaScript, so search and AI crawlers cannot see the menu, the internal links or the contact details. Write the header to _kaynak/ust.inc and the footer (name, address, phone, email, every page link, privacy notice, "Web: Opus Growth") to _kaynak/alt.inc. Use the .inc extension so seo-stamp and html-validate do not treat the fragments as pages. Every page carries the markers  and . Then write a dependency-free Node script with site_write_file at _kaynak/parca-bas.mjs: it stamps both fragments between the markers in every HTML file, adds aria-current="page" to the current page's menu link, and rewrites sitemap.xml using each page's JSON-LD dateModified as lastmod (skipping 404 and noindex pages). Build the mobile menu without JavaScript using <details><summary>Menu</summary>; the desktop and mobile menus are two separate <nav> elements with different aria-labels.
4. Host the fonts yourself. This site uses one classic serif family and three files at most. Download the Fontshare CSS (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap, weight code 401 for italic) with site_fetch to _kaynak/fontshare.css, read it with site_read_file and take only the woff2 URLs of the family you asked for; the service sometimes appends a family you did not request. Download each woff2 with site_fetch into assets/fonts/. Put the @font-face rules (font-display: swap) inside assets/app.css, because design-check.mjs only looks for a custom font in that file. Do not use the default Inter, Roboto, Poppins or Montserrat.
5. Compile Tailwind. assets/app.css becomes the Tailwind source: @tailwind base; @tailwind components; @tailwind utilities; at the top, then @font-face, the focus ring, the skip link, a prefers-reduced-motion rule and your own component classes inside @layer components. Never give a component class the name of a Tailwind utility (list-item, table, grid, container, hidden and so on), because the clash silently breaks the layout after compiling. Write tailwind.config.js at the root (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"], colours and fontFamily). Run "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" with site_run_command and background=true, and wait for it with site_command_status. Every page <head> holds, in this order: a single <link rel="stylesheet" href="/assets/site.css">, then one preload line for every font file used on the first screen (heading, accent and body; as="font" type="font/woff2" crossorigin). Preload lines placed before the stylesheet delay the CSS and lengthen LCP; a first-screen font left without preload swaps late, shifts the page and raises CLS, and <link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. The favicon line is required: without it the browser asks for /favicon.ico, gets a 404, and the console error lowers Best Practices.
6. Images. Download photos with site_fetch using resize and image_format="webp" at several widths (480, 800, 1200 and 1600 for the first-screen image, 480, 800 and 1200 for the rest; quality between 60 and 75, lower for detailed photos). Every <img> has srcset, sizes that match the real layout, width and height (zero CLS) and a meaningful, honest alt text. fetchpriority="high" goes only on the image Lighthouse reports as the LCP element, and that image is not lazy; every other image uses loading="lazy". If the LCP element is text, no image gets fetchpriority. Also prepare assets/img/logo.png, a 1200x630 assets/img/og.jpg and assets/img/favicon.svg.
7. HTML rules (html-validate defaults). <!DOCTYPE html> in upper case; no inline style attribute (including the kit's style="background:var(--brand)", use a class instead); &nbsp; instead of plain spaces in the text of tel: links; a type on every <button>; no trailing whitespace; tables with <thead>, <tbody> and th scope. Links inside paragraphs are underlined; menu, footer, breadcrumb and button links have a touch area of at least 44x44 pixels (min-h-[44px] min-w-[44px]).
8. Structured data. Fill the seo block in site.config.js (siteUrl, description, logo, og image, business type, address fields) and run "node seo-stamp.mjs" with site_run_command; it stamps Organization, WebSite and, where relevant, a LocalBusiness subtype, plus canonical and OG tags. Add page-specific schema by hand: on every page a WebPage node with an @id (or AboutPage, ContactPage, CollectionPage, ProfilePage), datePublished and dateModified, isPartOf #site, about #business or #org, and breadcrumb pointing to a BreadcrumbList; plus a Product with Offer per item on the products page, HowTo on the production page and FAQPage on the FAQ page. Write each node in its OWN <script type="application/ld+json"> block and do not use an @graph wrapper, because seo-check.mjs only reads the top-level @type and misses a BreadcrumbList inside @graph. Link the nodes with @id. Never invent opening hours, coordinates, ratings, reviews, awards, customer counts or certificates; leave unknown fields out.
9. AI access. Write robots.txt: the whole site open, only /_kaynak/ closed; Allow: / for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended and Bingbot; your decision on CCBot with the reason as a comment; the Sitemap line last. Add llms.txt at the root: a correct two-sentence summary of the business, the important pages with one line each, and contact details. Write 404.html (noindex, with the header and footer markers).
10. Writing. Each page has at least 150 words of original text inside <main>, and the first paragraph answers the page's main question directly. Titles are 48 to 60 characters, descriptions 145 to 158, unique on every page. No em dashes or en dashes, no stock slogans, no empty promises. If anything on the site is not real, say clearly that it is fictional.

Gates. After every change, run these with site_run_command in this order and do not move on until each one is clean:
1. node _kaynak/parca-bas.mjs, node seo-stamp.mjs, the Tailwind build (again if you added classes).
2. node seo-check.mjs: 0 errors and 0 warnings. If it warns "gövde kısa" (body too short), add real text, not filler.
3. node design-check.mjs: 0 errors. The only warning may be "Hiç hareket yok" (no motion); the classic style calls for it, so give the reason in the report.
4. npx --yes html-validate "**/*.html": 0 errors.
5. Look at every page with site_preview at view="mobile" and view="desktop", and check the home page at 360 and 768 pixels as well. Fix any horizontal overflow, cramped heading or touch target smaller than 44 pixels and look again.
6. Measure every page with core_web_vitals at strategy="mobile" and strategy="desktop", then audit the home page and the longest page with seo_audit. Target: on mobile, Accessibility, Best Practices and SEO 100 and Performance at least 95; on desktop all four at least 95. Not a single request may leave the site. If LCP is high, use resources=true to find the file holding it back: usually preload lines placed before the stylesheet, or fetchpriority given to an image that is not the LCP element. If CLS exceeds 0.1, look for a first-screen font that is not preloaded.
Do not call the job done until all of these pass.

Hand-over report: a table with the four Lighthouse scores and LCP per page on mobile and desktop, the result of the four gates, the reason behind any design-check warning, a list of information on the site that is fictional or missing, and what I still need to do (Google Business Profile, real photos, opening hours and so on).

WebsiteChanges after your approvalLive demo

Build a Swiss-minimal law or accounting firm site with strong trust signals

Has your assistant build a still firm site on a strict grid, with hierarchy carried by a single type family. It puts the trust signals a YMYL field needs on the page: practitioner profiles, a dated and sourced guidance note, wording that respects professional advertising rules, and Person schema.

When to use itWhen a law, accounting or similar professional practice needs a site that looks serious and plain, stays within professional advertising rules and proves its expertise.

Build a Swiss-minimal, multi-page static site for our practice on my Opus Growth hosting server [server name]. Practice: [practice name], [profession, e.g. law firm or accounting practice], [city]. Practice areas: [areas]. Practitioners: [for each, name, title, bar or chamber they are registered with, registration number, areas]. Phone: [phone], email: [email], address: [address], domain: [domain]. Guidance note topic: [a frequently asked topic, e.g. the legal cap on rent increases].

This is a field where people make decisions about their money and their rights, so trust has to come from clarity, credentials and sources, not decoration. Respect the professional rules: for lawyers in Turkey the Union of Turkish Bar Associations' advertising ban regulation, for accountants TÜRMOB's professional rules, or the equivalent where you practise. Do not write success rates, numbers of cases won, client names, superiority claims such as "best" or "leading expert", fee comparisons, guarantees or exaggerated promises. Present information with a note that it is general and does not replace legal or financial advice.

The design direction is Swiss-minimal:
1. Type: one grotesk family from Fontshare (e.g. Switzer 400, 500, 600). Hierarchy comes only from size and weight: a large, tight, left-aligned heading, calm body text, small section labels.
2. Colour: white background, near-black text, one dark grey and a single accent (e.g. Swiss red). The accent appears only on the section mark, labels and the focus ring. Photos are black and white (Tailwind grayscale).
3. Grid: a strict 12 columns. In every section the label sits in columns 1 to 3 and the content in 4 to 12; sections are separated by a 1-pixel black rule. No rounded corners or shadows.
4. Signature element: section labels numbered with a § mark in the accent colour, and faint 12-column guide lines drawn in CSS only behind the first screen.
5. Motion: none.

Pages and their schema:
1. index.html: a first screen whose opening paragraph answers "which matters, for whom, where", the practice areas, how you work and how fees are set (no figures, the official tariff and a written engagement letter), the latest guidance note, a team summary. WebPage.
2. calisma-alanlari.html: one section per area; the first paragraph answers the most common question in that area, followed by the main topics and the legal basis. A Service per area.
3. ekip.html: a profile for each practitioner (name, title, bar or chamber, areas, short biography). AboutPage and a Person per practitioner (jobTitle, knowsAbout, worksFor #business, memberOf the bar or chamber).
4. bilgi-notlari/[topic].html: a note grounded in the statute that opens with a short answer. At the top: author, reviewer, publication date and last review date; at the end a list of sources. Article (author and publisher via @id, image, datePublished, dateModified, citation) and reviewedBy plus lastReviewed on the WebPage. Never write a legal or financial point you do not know; ask me about every sentence you are unsure of.
5. sss.html: six real questions, FAQPage. 6. iletisim.html: ContactPage. 7. kvkk.html (mentioning professional confidentiality) and 404.html.

Technical rules. Follow them exactly, because the gates below measure exactly these:

1. Setup. Run scaffold_site as a preview first, show me the file list, and install with confirm=true after I approve. Then read site_design_guide and site_seo_guide in full. Before writing any code, write the direction in _kaynak/ART.md (feel, font pairing, colours with contrast ratios, grid, signature element, motion decision, page list) and show it to me.
2. Strip out JavaScript. No page on this site loads any JavaScript. Remove from every page the cdn.tailwindcss.com script, the tailwind.config line, the GSAP, ScrollTrigger, SplitText, Lenis and Swiper tags and the motion.js, chrome.js and site.config.js script tags; delete assets/chrome.js and assets/motion.js. Keep assets/site.config.js, but only as the brand, contact and seo source for seo-stamp.mjs; it is never loaded in the browser.
3. Menu and footer are static HTML. The <site-nav> and <site-footer> components are drawn by JavaScript, so search and AI crawlers cannot see the menu, the internal links or the contact details. Write the header to _kaynak/ust.inc and the footer (name, address, phone, email, every page link, privacy notice, "Web: Opus Growth") to _kaynak/alt.inc. Use the .inc extension so seo-stamp and html-validate do not treat the fragments as pages. Every page carries the markers  and . Then write a dependency-free Node script with site_write_file at _kaynak/parca-bas.mjs: it stamps both fragments between the markers in every HTML file, adds aria-current="page" to the current page's menu link, and rewrites sitemap.xml using each page's JSON-LD dateModified as lastmod (skipping 404 and noindex pages). Build the mobile menu without JavaScript using <details><summary>Menu</summary>; the desktop and mobile menus are two separate <nav> elements with different aria-labels.
4. Host the fonts yourself. This site uses one font family and three files at most. Download the Fontshare CSS (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap, weight code 401 for italic) with site_fetch to _kaynak/fontshare.css, read it with site_read_file and take only the woff2 URLs of the family you asked for; the service sometimes appends a family you did not request. Download each woff2 with site_fetch into assets/fonts/. Put the @font-face rules (font-display: swap) inside assets/app.css, because design-check.mjs only looks for a custom font in that file. Do not use the default Inter, Roboto, Poppins or Montserrat.
5. Compile Tailwind. assets/app.css becomes the Tailwind source: @tailwind base; @tailwind components; @tailwind utilities; at the top, then @font-face, the focus ring, the skip link, a prefers-reduced-motion rule and your own component classes inside @layer components. Never give a component class the name of a Tailwind utility (list-item, table, grid, container, hidden and so on), because the clash silently breaks the layout after compiling. Write tailwind.config.js at the root (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"], colours and fontFamily). Run "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" with site_run_command and background=true, and wait for it with site_command_status. Every page <head> holds, in this order: a single <link rel="stylesheet" href="/assets/site.css">, then one preload line for every font file used on the first screen (heading, accent and body; as="font" type="font/woff2" crossorigin). Preload lines placed before the stylesheet delay the CSS and lengthen LCP; a first-screen font left without preload swaps late, shifts the page and raises CLS, and <link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. The favicon line is required: without it the browser asks for /favicon.ico, gets a 404, and the console error lowers Best Practices.
6. Images. Download photos with site_fetch using resize and image_format="webp" at several widths (480, 800, 1200 and 1600 for the first-screen image, 480, 800 and 1200 for the rest; quality between 60 and 75, lower for detailed photos). Every <img> has srcset, sizes that match the real layout, width and height (zero CLS) and a meaningful, honest alt text. fetchpriority="high" goes only on the image Lighthouse reports as the LCP element, and that image is not lazy; every other image uses loading="lazy". If the LCP element is text, no image gets fetchpriority. Also prepare assets/img/logo.png, a 1200x630 assets/img/og.jpg and assets/img/favicon.svg.
7. HTML rules (html-validate defaults). <!DOCTYPE html> in upper case; no inline style attribute (including the kit's style="background:var(--brand)", use a class instead); &nbsp; instead of plain spaces in the text of tel: links; a type on every <button>; no trailing whitespace; tables with <thead>, <tbody> and th scope. Links inside paragraphs are underlined; menu, footer, breadcrumb and button links have a touch area of at least 44x44 pixels (min-h-[44px] min-w-[44px]).
8. Structured data. Fill the seo block in site.config.js (siteUrl, description, logo, og image, business type, address fields) and run "node seo-stamp.mjs" with site_run_command; it stamps Organization, WebSite and, where relevant, a LocalBusiness subtype, plus canonical and OG tags. Add page-specific schema by hand: on every page a WebPage node with an @id (or AboutPage, ContactPage, CollectionPage, ProfilePage), datePublished and dateModified, isPartOf #site, about #business or #org, and breadcrumb pointing to a BreadcrumbList; plus a Service per practice area, a Person per practitioner on the team page, Article and reviewedBy on the guidance note, and FAQPage on the FAQ page. Write each node in its OWN <script type="application/ld+json"> block and do not use an @graph wrapper, because seo-check.mjs only reads the top-level @type and misses a BreadcrumbList inside @graph. Link the nodes with @id. Never invent opening hours, coordinates, ratings, reviews, awards, customer counts or certificates; leave unknown fields out.
9. AI access. Write robots.txt: the whole site open, only /_kaynak/ closed; Allow: / for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended and Bingbot; your decision on CCBot with the reason as a comment; the Sitemap line last. Add llms.txt at the root: a correct two-sentence summary of the business, the important pages with one line each, and contact details. Write 404.html (noindex, with the header and footer markers).
10. Writing. Each page has at least 150 words of original text inside <main>, and the first paragraph answers the page's main question directly. Titles are 48 to 60 characters, descriptions 145 to 158, unique on every page. No em dashes or en dashes, no stock slogans, no empty promises. If anything on the site is not real, say clearly that it is fictional.

Gates. After every change, run these with site_run_command in this order and do not move on until each one is clean:
1. node _kaynak/parca-bas.mjs, node seo-stamp.mjs, the Tailwind build (again if you added classes).
2. node seo-check.mjs: 0 errors and 0 warnings. If it warns "gövde kısa" (body too short), add real text, not filler.
3. node design-check.mjs: 0 errors. The only warning may be "Hiç hareket yok" (no motion); the style calls for it, so give the reason in the report.
4. npx --yes html-validate "**/*.html": 0 errors.
5. Look at every page with site_preview at view="mobile" and view="desktop", and check the home page at 360 and 768 pixels as well. Fix any horizontal overflow, cramped heading or touch target smaller than 44 pixels and look again.
6. Measure every page with core_web_vitals at strategy="mobile" and strategy="desktop", then audit the home page and the longest page with seo_audit. Target: on mobile, Accessibility, Best Practices and SEO 100 and Performance at least 95; on desktop all four at least 95. Not a single request may leave the site. If LCP is high, use resources=true to find the file holding it back: usually preload lines placed before the stylesheet, or fetchpriority given to an image that is not the LCP element. If CLS exceeds 0.1, look for a first-screen font that is not preloaded.
Do not call the job done until all of these pass.

WebsiteChanges after your approvalLive demo

Build a JavaScript-free multi-page corporate site and deliver it at 100

Has your assistant build a still, fast and accessible site for corporate work such as architecture, engineering or consulting. Menu and footer are static HTML, fonts and CSS are self-hosted, and every page is measured before hand-over.

When to use itWhen a corporate business needs a multi-page site where speed and accessibility matter more than decoration, with no animation and no JavaScript.

Build a corporate, multi-page, fully static site for my business on my Opus Growth hosting server [server name]. Business: [business name], [sector, e.g. engineering and architecture practice], [city/service area]. Services: [services with a short description each]. Phone: [phone], email: [email], address: [address], domain: [domain]. Colour preference: [colour/brand preference, or "your choice"]. Photos: [where the real photos are, or "use suitable stock photos"].

This site puts speed and accessibility first. Not a single line of JavaScript on any page; GSAP, Lenis and Swiper are never loaded. Everything, including the menu, the mobile menu and the FAQ, works with HTML and CSS.

The design direction is "technical drawing sheet":
1. Type: a tight grotesk heading font from Fontshare (e.g. Cabinet Grotesk 800) and a calm body font (e.g. General Sans 400 and 600). Three font files at most.
2. Colour: a light paper-tone background, dark ink text, a secondary grey and one signal-colour accent. The accent appears only on labels, thin rules and the main button. Every text colour reaches at least 4.5:1 contrast.
3. Grid: 12 columns, sections separated by 1-pixel rules; no shadows, rounded corners or gradients.
4. Signature element: under the first-screen image, a four-cell strip styled like the title block of an architectural drawing (e.g. project type, code followed, scale, sheet number), and a very faint millimetre grid drawn in CSS only behind the first screen.
5. Motion: none. No transition durations either; only underline and colour change instantly on hover.

Pages and their schema:
1. index.html: a first screen whose opening paragraph directly answers "what do you do, for whom, where", three service cards (each linking to its section), a four-step process (numbered "Step 1" with a CSS counter, not 01/02), two project examples, a phone band. WebPage.
2. hizmetler.html: one section per service; the first paragraph answers "when is it needed, what does it do", then a scope list, typical duration and deliverables. WebPage plus a Service per service (provider #business, areaServed).
3. projeler.html: examples with building type, method and outcome; client names only with permission. CollectionPage.
4. hakkimizda.html: who we are, our working rules, where we work. AboutPage.
5. sss.html: at least six real questions inside <details>. WebPage and FAQPage.
6. iletisim.html: phone, email and address inside <address>, a map link; leave hours out if you do not know them. ContactPage with mainEntity #business.
7. kvkk.html (privacy notice) and 404.html.

Technical rules. Follow them exactly, because the gates below measure exactly these:

1. Setup. Run scaffold_site as a preview first, show me the file list, and install with confirm=true after I approve. Then read site_design_guide and site_seo_guide in full. Before writing any code, write the direction in _kaynak/ART.md (feel, font pairing, colours with contrast ratios, grid, signature element, motion decision, page list) and show it to me.
2. Strip out JavaScript. No page on this site loads any JavaScript. Remove from every page the cdn.tailwindcss.com script, the tailwind.config line, the GSAP, ScrollTrigger, SplitText, Lenis and Swiper tags and the motion.js, chrome.js and site.config.js script tags; delete assets/chrome.js and assets/motion.js. Keep assets/site.config.js, but only as the brand, contact and seo source for seo-stamp.mjs; it is never loaded in the browser.
3. Menu and footer are static HTML. The <site-nav> and <site-footer> components are drawn by JavaScript, so search and AI crawlers cannot see the menu, the internal links or the contact details. Write the header to _kaynak/ust.inc and the footer (name, address, phone, email, every page link, privacy notice, "Web: Opus Growth") to _kaynak/alt.inc. Use the .inc extension so seo-stamp and html-validate do not treat the fragments as pages. Every page carries the markers  and . Then write a dependency-free Node script with site_write_file at _kaynak/parca-bas.mjs: it stamps both fragments between the markers in every HTML file, adds aria-current="page" to the current page's menu link, and rewrites sitemap.xml using each page's JSON-LD dateModified as lastmod (skipping 404 and noindex pages). Build the mobile menu without JavaScript using <details><summary>Menu</summary>; the desktop and mobile menus are two separate <nav> elements with different aria-labels.
4. Host the fonts yourself. This site uses three font files at most. Download the Fontshare CSS (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap, weight code 401 for italic) with site_fetch to _kaynak/fontshare.css, read it with site_read_file and take only the woff2 URLs of the family you asked for; the service sometimes appends a family you did not request. Download each woff2 with site_fetch into assets/fonts/. Put the @font-face rules (font-display: swap) inside assets/app.css, because design-check.mjs only looks for a custom font in that file. Do not use the default Inter, Roboto, Poppins or Montserrat.
5. Compile Tailwind. assets/app.css becomes the Tailwind source: @tailwind base; @tailwind components; @tailwind utilities; at the top, then @font-face, the focus ring, the skip link, a prefers-reduced-motion rule and your own component classes inside @layer components. Never give a component class the name of a Tailwind utility (list-item, table, grid, container, hidden and so on), because the clash silently breaks the layout after compiling. Write tailwind.config.js at the root (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"], colours and fontFamily). Run "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" with site_run_command and background=true, and wait for it with site_command_status. Every page <head> holds, in this order: a single <link rel="stylesheet" href="/assets/site.css">, then one preload line for every font file used on the first screen (heading, accent and body; as="font" type="font/woff2" crossorigin). Preload lines placed before the stylesheet delay the CSS and lengthen LCP; a first-screen font left without preload swaps late, shifts the page and raises CLS, and <link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. The favicon line is required: without it the browser asks for /favicon.ico, gets a 404, and the console error lowers Best Practices.
6. Images. Download photos with site_fetch using resize and image_format="webp" at several widths (480, 800, 1200 and 1600 for the first-screen image, 480, 800 and 1200 for the rest; quality between 60 and 75, lower for detailed photos). Every <img> has srcset, sizes that match the real layout, width and height (zero CLS) and a meaningful, honest alt text. fetchpriority="high" goes only on the image Lighthouse reports as the LCP element, and that image is not lazy; every other image uses loading="lazy". If the LCP element is text, no image gets fetchpriority. Also prepare assets/img/logo.png, a 1200x630 assets/img/og.jpg and assets/img/favicon.svg.
7. HTML rules (html-validate defaults). <!DOCTYPE html> in upper case; no inline style attribute (including the kit's style="background:var(--brand)", use a class instead); &nbsp; instead of plain spaces in the text of tel: links; a type on every <button>; no trailing whitespace; tables with <thead>, <tbody> and th scope. Links inside paragraphs are underlined; menu, footer, breadcrumb and button links have a touch area of at least 44x44 pixels (min-h-[44px] min-w-[44px]).
8. Structured data. Fill the seo block in site.config.js (siteUrl, description, logo, og image, business type, address fields) and run "node seo-stamp.mjs" with site_run_command; it stamps Organization, WebSite and, where relevant, a LocalBusiness subtype, plus canonical and OG tags. Add page-specific schema by hand: on every page a WebPage node with an @id (or AboutPage, ContactPage, CollectionPage, ProfilePage), datePublished and dateModified, isPartOf #site, about #business or #org, and breadcrumb pointing to a BreadcrumbList; plus a Service per service on the services page and FAQPage on the FAQ page. Write each node in its OWN <script type="application/ld+json"> block and do not use an @graph wrapper, because seo-check.mjs only reads the top-level @type and misses a BreadcrumbList inside @graph. Link the nodes with @id. Never invent opening hours, coordinates, ratings, reviews, awards, customer counts or certificates; leave unknown fields out.
9. AI access. Write robots.txt: the whole site open, only /_kaynak/ closed; Allow: / for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended and Bingbot; your decision on CCBot with the reason as a comment; the Sitemap line last. Add llms.txt at the root: a correct two-sentence summary of the business, the important pages with one line each, and contact details. Write 404.html (noindex, with the header and footer markers).
10. Writing. Each page has at least 150 words of original text inside <main>, and the first paragraph answers the page's main question directly. Titles are 48 to 60 characters, descriptions 145 to 158, unique on every page. No em dashes or en dashes, no stock slogans, no empty promises. If anything on the site is not real, say clearly that it is fictional.

Gates. After every change, run these with site_run_command in this order and do not move on until each one is clean:
1. node _kaynak/parca-bas.mjs, node seo-stamp.mjs, the Tailwind build (again if you added classes).
2. node seo-check.mjs: 0 errors and 0 warnings. If it warns "gövde kısa" (body too short), add real text, not filler.
3. node design-check.mjs: 0 errors. The only warning may be "Hiç hareket yok" (no motion); that is this site's deliberate choice, so give the reason in the report.
4. npx --yes html-validate "**/*.html": 0 errors.
5. Look at every page with site_preview at view="mobile" and view="desktop", and check the home page at 360 and 768 pixels as well. Fix any horizontal overflow, cramped heading or touch target smaller than 44 pixels and look again.
6. Measure every page with core_web_vitals at strategy="mobile" and strategy="desktop", then audit the home page and the longest page with seo_audit. Target: on mobile, Accessibility, Best Practices and SEO 100 and Performance at least 95; on desktop all four at least 95. Not a single request may leave the site. If LCP is high, use resources=true to find the file holding it back: usually preload lines placed before the stylesheet, or fetchpriority given to an image that is not the LCP element. If CLS exceeds 0.1, look for a first-screen font that is not preloaded.
Do not call the job done until all of these pass.