Fill in before sending
[server name][full name][specialism, e.g. export consultant][area I serve, or "online"][services][phone][email][domain][topic 1][topic 2][address or "none"][article]
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 <!-- ust:bas --><!-- ust:son --> and <!-- alt:bas --><!-- alt:son -->. 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); 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.
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 mi