Website

Set a robots.txt policy for AI crawlers and publish it safely

Helps you decide which AI crawlers the site should be open to by separating search, user fetch and training roles. Previews a new robots.txt that keeps your existing rules, writes it to your hosted site or WordPress after approval and verifies it live.

When to use it

You want your site to be cited in AI search but want to decide separately about model training, or you do not know what your robots.txt tells AI crawlers today.

What you get

A before and after decision table for every AI crawler, a new robots.txt that keeps your existing private-area rules, the file published after your approval and verified live, and the version you can roll back to.

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

SEO Intelligence, WordPress

Fill in before sending

[site URL][Opus Growth hosting or WordPress]

Rework the robots.txt of my site [site URL] around a deliberate policy for AI crawlers. Site type: [Opus Growth hosting or WordPress]. My preference: [A: open to all / B: search open, training closed / C: custom, explain]. 1. Read the current state. Read [site URL]/robots.txt with site_read_url. If the site is on Opus Growth hosting, also read robots.txt with site_read_file and confirm it matches what is live. If it is WordPress, find out which SEO plugin runs it with wordpress_seo and check with wordpress_snippet action='list' whether any snippet already touches robots.txt. List every existing rule group, every Disallow line and every Sitemap line. 2. Explain the roles. Put the crawlers into three groups and tell me in one sentence each what I lose or gain: 1. Search and citation: OAI-SearchBot, Claude-SearchBot, PerplexityBot, Bingbot, Googlebot, Applebot. Closing these stops the site from being cited as a source in that assistant's answers. 2. Live fetch on behalf of a user: ChatGPT-User, Claude-User, Perplexity-User. These arrive when a user shares my link or the assistant opens a page to answer. According to the providers' documentation, robots.txt may not apply in every case to these user-initiated requests, so say that a rule here is not a guarantee. 3. Model training: GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, CCBot, meta-externalagent. Closing these limits use of the content in future training, it does not remove content from models already trained. Closing Google-Extended does not affect Google Search or AI Overviews. 3. Write the draft. Prepare the new robots.txt for my preference and follow these rules: 1. Once you write a group under a crawler's own name, that crawler no longer reads the `User-agent: *` group. So copy every Disallow line from the * group (admin area, cart, internal search results and so on) into every named group, otherwise you will open private areas without noticing. 2. Do not block CSS, JavaScript or image files, because crawlers need them to render the page. 3. Keep the existing Sitemap lines, and add the full sitemap URL if it is missing. 4. Do not close any search-role crawler unless I explicitly ask for it. 5. Leave competitor SEO crawlers (such as AhrefsBot and SemrushBot) alone unless I ask, they are outside the scope of this job. 4. Show a preview. Compare the old and new file line by line, and show a table with the before and after decision for each crawler: crawler, role, old decision, new decision. Wait for my approval. 5. Apply after approval. 1. Hosted site: write robots.txt with site_write_file. The platform takes a version snapshot before each write, so tell me which version from site_versions I can return to. 2. WordPress: when no physical file exists on the server, WordPress generates robots.txt itself and the `robots_txt` filter can change it. Create a PHP snippet with wordpress_snippet that uses this filter, location 'everywhere'. The snippet is created inactive, so show me the code and turn it on only after I approve. If a cache plugin is active, clear the cache with wordpress_purge_cache. 6. Read it back. Read robots.txt again with site_read_url and show that the new content is live. On WordPress, if the content did not change, there is a physical robots.txt file on the server and the filter cannot reach it. In that case turn the snippet off and walk me through changing the file in the SEO plugin's file editor (Yoast: Tools, File editor; Rank Math: General Settings, Edit robots.txt) or in the hosting panel. End with a two-sentence note: the change takes effect when crawlers re-read the file (usually within a day), and if a CDN or firewall rule blocks by crawler name, robots.txt alone is not enough.

1. Read the current state. Read [site URL]/robots.txt with site_read_url. If the site is on Opus Growth hosting, also read robots.txt with site_read_file and confirm it matches what is live. If it is WordPress, find out which SEO plugin runs it with wordpress_seo and check with wordpress_snippet action='list' whether any snippet already touches robots.txt. List every existing rule group, every Disallow line and every Sitemap line.
2. Explain the roles. Put the crawlers into three groups and tell me in one sentence each what I lose or gain:
   1. Search and citation: OAI-SearchBot, Claude-SearchBot, PerplexityBot, Bingbot, Googlebot, Applebot. Closing these stops the site from being cited as a source in that assistant's answers.
   2. Live fetch on behalf of a user: ChatGPT-User, Claude-User, Perplexity-User. These arrive when a user shares my link or the assistant opens a page to answer. According to the providers' documentation, robots.txt may not apply in every case to these user-initiated requests, so say that a rule here is not a guarantee.
   3. Model training: GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, CCBot, meta-externalagent. Closing these limits use of the content in future training, it does not remove content from models already trained. Closing Google-Extended does not affect Google Search or AI Overviews.
3. Write the draft. Prepare the new robots.txt for my preference and follow these rules:
   1. Once you write a group under a crawler's own name, that crawler no longer reads the `User-agent: *` group. So copy every Disallow line from the * group (admin area, cart, internal search results and so on) into every named group, otherwise you will open private areas without noticing.
   2. Do not block CSS, JavaScript or image files, because crawlers need them to render the page.
   3. Keep the existing Sitemap lines, and add the full sitemap URL if it is missing.
   4. Do not close any search-role crawler unless I explicitly ask for it.
   5. Leave competitor SEO crawlers (such as AhrefsBot and SemrushBot) alone unless I ask, they are outside the scope of this job.
4. Show a preview. Compare the old and new file line by line, and show a table with the before and after decision for each crawler: crawler, role, old decision, new decision. Wait for my approval.
5. Apply after approval.
   1. Hosted site: write robots.txt with site_write_file. The platform takes a version snapshot before each write, so tell me which version from site_versions I can return to.
   2. WordPress: when no physical file exists on the server, WordPress generates robots.txt itself and the `robots_txt` filter can change it. Create a PHP snippet with wordpress_snippet that uses this filter, location 'everywhere'. The snippet is created inactive, so show me the code and turn it on only after I approve. If a cache plugin is active, clear the cache with wordpress_purge_cache.
6. Read it back. Read robots.txt again with site_read_url and show that the new content is live. On WordPress, if the content did not change, there is a physical robots.txt file on the server and the filter cannot reach it. In that case turn the snippet off and walk me through changing the file in the SEO plugin's file editor (Yoast: Tools, File editor; Rank Math: General Settings, Edit robots.txt) or in the hosting panel.

End with a two-sentence note: the change takes effect when crawlers re-read the file (usually within a day), and if a CDN or firewall rule blocks by crawler name, robots.txt alone is not enough.

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)

The current file has two groups: User-agent: * (Disallow: /panel/, /cart/) and User-agent: GPTBot (Disallow: /). Your preference is B: search open, training closed.

Crawler	Role	Old decision	New decision
OAI-SearchBot	Search	Allowed	Allowed
Claude-SearchBot	Search	Allowed	Allowed
PerplexityBot	Search	Allowed	Allowed
ChatGPT-User	User fetch	Allowed	Allowed
GPTBot	Training	Blocked	Blocked
ClaudeBot	Training	Allowed	Blocked
Google-Extended	Training	Allowed	Blocked
CCBot	Training	Allowed	Blocked

Note: the old GPTBot group did not repeat the /panel/ and /cart/ lines. That was harmless there because the group closed the whole site, but in the new file both lines are written into every named group.

After your approval robots.txt was written with site_write_file. site_read_url read it live, it returned 200 and shows the new content. To roll back, the 14:02 version in site_versions holds the old file.

Note: crawlers usually re-read the file within a day. If a firewall rule blocks by crawler name, robots.txt alone is not enough.

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.