标签：#seo

I run TextTimeTools , a free site with speaking-time and reading-time calculators. It's a pure static site deployed to Cloudflare Pages — no backend, no database, no CMS. The calculators themselves are one page. But the site has 50+ pages , each targeting a different keyword like "how many words is a 5 minute speech" or "how long to read 1000 words". Every single one of those pages is generated by a build script. I've never written one by hand. Here's the pattern, and why it's the highest-leverage thing I've done for this site's organic traffic. The problem with a single calculator page A speaking-time calculator answers one query well: "how many words is my speech". But people don't search for tools — they search for answers : "how many words is a 5 minute speech" "how many words for a 3 minute speech" "how long to read 1000 words" "how long to read 5000 words" Each of those is a separate keyword with its own search intent and its own competition. One calculator page can't rank for all of them — a page titled "Speaking Time Calculator" has no reason to show up for "how long to read 1000 words". The classic fix is to write a page per keyword. That works, but it doesn't scale — every new keyword means hand-writing another page, and keeping them consistent is a nightmare. The fix: generate pages at build time The build script ( gen-longtail.cjs ) takes a list of keyword targets and emits a complete, keyword-specific HTML page for each one. The word count pages and reading time pages are both generated this way. const PAGES = [ { minutes : 1 , slug : ' how-many-words-is-a-1-minute-speech ' , variant : ' is-a ' }, { minutes : 2 , slug : ' how-many-words-is-a-2-minute-speech ' , variant : ' is-a ' }, { minutes : 5 , slug : ' how-many-words-is-a-5-minute-speech ' , variant : ' is-a ' }, // ... up to 15 minutes { minutes : 2 , slug : ' how-many-words-for-a-2-minute-speech ' , variant : ' for-a ' }, { minutes : 5 , slug : ' how-many-words-for-a-5-minute-speech ' , variant :

Originally published on michael-kaminski.io . The Genome of Games publishes the same 1,180 records four different ways, and one command writes all four: node build.js , 0.39 seconds, zero npm dependencies. Out come 1,245 static HTML pages for crawlers, an interactive canvas graph for humans, a 129,037-byte search index for the site's own search box, and a Model Context Protocol server exposing 8 tools to agents. The decision worth copying is the one that sounds like a downgrade. The MCP server does not query the site and does not read the source data. It statically imports a 1.9 MB index that the build wrote. There is exactly one place where slugs, lineage, and adoption edges get joined, so an agent and a crawler cannot come back with different answers. The dataset is an ontology of video game mechanics — 168 mechanics, 618 games, 394 companies, 4,366 recorded links, 1962 to 2025. What the records are about does not matter here. The shape of the problem shows up anywhere a structured knowledge base has to serve both a search engine and a model. Four surfaces, one build, a twelve-fold expansion Six hand-edited JSON files under data/ are the source of truth: the feature ontology, the graph, the prose, the company registry, the site copy, and the verified outbound links. Together they are 1,312,577 bytes. The build turns that into 16,644,215 bytes of generated read surface. A 12.7× expansion, and every byte of it is disposable. Surface Consumer Bytes Per entity 1,245 static HTML pages Crawlers, humans 14,613,203 11,728 / page mcp-index.json → MCP server Agents 1,901,975 1,612 search-index.json The site's own search box 129,037 109 /graph/ canvas Humans exploring lineage data injected at build — The build also emits sitemap.xml with 1,245 entries, llms.txt , robots.txt , and a 404 page. The same run reports 96,843 internal links across those pages. Nothing in that list is authored. Delete the whole output directory and the next build restores it in under half a second.

Ranking on Google is no longer the same thing as earning a click. Search engines increasingly answer questions directly through AI Overviews, featured snippets, People Also Ask boxes, local results, and other search features. In early 2026, a SparkToro study reported by Search Engine Land estimated that 68.01% of U.S. Google searches ended without a click during the first four months of the year. The comparison needs to be interpreted carefully because different studies use different data panels, but the direction is clear: a search impression does not automatically become a website visit. For small websites, this does not mean that SEO is dead. It means the goal is becoming broader. A useful page should be easy to discover, easy to understand, worthy of being cited, and valuable enough that a searcher wants to continue reading after seeing the short answer. SEO still matters in AI search Google's official guidance says that SEO remains relevant for generative search features because AI Overviews and AI Mode are grounded in Google's core Search ranking and quality systems. Google recommends the same fundamentals that have always helped users and crawlers: valuable original content, clear organization, crawlability, good page experience, and accurate technical implementation. This is important because there is no reliable shortcut called “GEO magic.” Google specifically says that site owners do not need special AI-only markup or an llms.txt file to appear in Google Search. The practical approach is still to build a website that people can use and trust. The question is therefore not only, “How do I rank for this keyword?” A better question is, “If an AI system or search feature reads my page, will it find a clear, specific, well-supported answer that represents my experience?” The four layers of visibility A small website can think about search visibility in four layers: Layer What it means Example signal Discovery Search engines can find and crawl the page Internal

An RV repair business does not lose a service call because a visitor failed to read a clever headline. It loses the call when a person with a broken slide-out, roof leak, or electrical issue cannot answer four basic questions quickly: Do you handle this exact problem? Do you serve where I am? Are you available and credible? What do I do next? That sounds like marketing. It is mostly a systems-design problem. The implementation goal is not “make more city pages.” It is to make the business's real-world facts available, consistent, crawlable, and usable across the website, Google Business Profile, analytics, and the conversion flow. This post turns SEOG’s RV repair checklist into an implementation pattern a developer can apply to any local-service site. The model: one source of truth, many decision surfaces Local customers do not encounter a business in one place. They may see a Google result, a Maps profile, a service page, a review, or a call button before they ever submit a form. Treat the site as one consumer of a small, canonical business data model rather than a collection of independently written pages. business facts ─┬─> server-rendered service pages ├─> JSON-LD ├─> XML sitemap + canonical URLs ├─> GBP sync/review queue (with human approval) ├─> call/form events └─> audit and change history The important part is the left side. If a mobile RV technician's phone number, service coverage, repair categories, and hours live in five unrelated CMS fields, a mismatch is inevitable. Start with an explicit domain object. type BusinessLocation = { id : string ; legalName : string ; publicName : string ; phoneE164 : string ; website : string ; address ?: { streetAddress : string ; addressLocality : string ; addressRegion : string ; postalCode : string ; addressCountry : " US " ; }; geo ?: { latitude : number ; longitude : number }; serviceAreas : Array < { name : string ; state : string ; proof : string [] } > ; hours : Array < { dayOfWeek : string []; opens : string ; c

I run a search engine that publishes in twelve languages from one static site on Cloudflare Pages. Last week I audited its machine-readable layer — the part crawlers and answer engines read rather than humans — and found four problems. None of them threw an error. None appeared in logs. Every page rendered perfectly. That is the whole point of this post: the multilingual layer fails in a register where nothing tells you. 1. The homepage was serving the wrong language to everyone abroad The site's primary market speaks Hebrew, so / is Hebrew and /en/ , /ar/ , /de/ and nine others sit alongside it. A middleware rule redirected visitors from one specific region to their language. Everyone else — including every English speaker on earth — landed on Hebrew. My first instinct was to fix it with a broader geo-redirect: detect English-speaking countries, send them to /en/ . This would have been a bad idea, and it is worth saying why. Googlebot crawls predominantly from US IPs. A geo-redirect on / that keys off country would take the crawler off the Hebrew homepage and onto the English one almost every time it visited. You do not want your primary-market homepage to become the page the crawler can never reach. The correct tool is hreflang , and it is what search engines built for exactly this. Checking the page, the tags were already there and already right: <link rel= "alternate" hreflang= "he" href= "https://example.com/" > <link rel= "alternate" hreflang= "en" href= "https://example.com/en/" > <link rel= "alternate" hreflang= "ar" href= "https://example.com/ar/" > <!-- …ten more… --> <link rel= "alternate" hreflang= "x-default" href= "https://example.com/en/" > Two things make this work, and both are easy to get wrong: The set must be reciprocal. Every page in the group lists every other page including itself . If /en/ does not point back at / , search engines are entitled to ignore the whole cluster. x-default is not "the default language" — it is the fallback for users

Two numbers off my Search Console this morning, same 28 day window, same site. The free landing page roast tool: 42 impressions, average position 38.0. The blog post I wrote to support that tool: 11 impressions, average position 21.1. Six weeks earlier it was the other way round. On July 4 the tool sat at position 7.5 on 18 impressions and the article was at 17.8 on 38. So the tool has more than doubled its reach since then, and its average position has gotten roughly five times worse over the same stretch. Both of those things are true at once, and working out why changed how I plan the next tool. The tool favors.dev/roast takes a URL and gives back a conversion score out of 100. It screenshots your full public page, then grades the copy and the design together across six categories: clarity, value proposition, trust, CTA, visual design and SEO. You get back the specific issues hurting signups with a fix for each, the things the page already does well, and a one line verdict. No signup, no credit card, no email field. Paste a URL, press "Roast it", read the result. It is deliberately small, and the scoping is most of why it shipped. The cut list was: accounts and password resets, saved history, dashboards, billing and usage limits, settings and themes, support for every edge case, and an admin panel for myself. Every one of those is how a weekend build turns into a month. If a free tool needs a billing system, you have started building a second product by accident. What those numbers actually say Here is the honest read, because "my free tool beat 29 of my 32 blog posts" is technically true and a bit misleading. Reading Tool impressions Tool position Article impressions Article position Jul 4 18 7.5 38 17.8 Jul 11 20 7.1 42 16.9 Jul 19 22 10.4 39 19.1 Aug 15 42 38.0 11 21.1 Impressions climbed because the tool started matching a much wider spread of queries. Average position fell for exactly the same reason. It is not ranking better. It is ranking on more things, m

Build-in-public note, no fireworks. Why bother Search Console in mid-August was blunt: 6 of 1,098 pages indexed, the rest stuck at "Discovered – currently not indexed", and the Links report empty. Zero external backlinks. The site has a thousand free session pages that nobody can find because nothing points at them. Directories are the cheapest way to get the first handful of pointers, and they are also the corpora that AI assistants read when someone asks "what tools show SPX gamma exposure". So the goal was never traffic. It was (a) backlinks and (b) third-party mentions. What went in The same card everywhere: SPX dealer positioning rebuilt from the 0DTE tape; zero-gamma flip, call/put walls, hold band; every finished session free; a backtest Lab; an MCP server; no buy/sell signals. Logo from the favicon, three screenshots (terminal, the measured book, the Lab), category Finance / Investing wherever the menu allowed it. Done and live: Capterra, AlternativeTo, the official MCP registry (and glama.ai, which pulls from it), TradersList, Firsto, TinyLaunch, Startup Fame, Indie Hackers. Submitted and waiting on a human: StartupStash. Product Hunt is scheduled, one shot only. What we skipped, and why — this is the useful part Anything that wants a badge on our homepage for the free tier (Huzzler, Startup Fame's final step). The card is filled and sits unpublished. A measurement terminal with "featured on" stickers on it is a different product. AI-tool directories (Futurepedia, There's An AI For That). $300–$500 for a listing in front of an audience that wants image generators. The MCP server technically qualifies; the economics do not. Hashnode. Published a 1,300-word engineering write-up; AutoMod archived it within the hour as "this type of content" on a free subdomain, with an upsell to Pro. The Markdown is saved; it will go out on dev.to instead. Reddit. Not a channel for this product. Decided, not deferred. Paid "we submit you to 140 directories" packages. Every one

I Tested 5 AI Engines On My Own Sites. None Agreed. In July I wrote that my open-source...

Eight user agents, and the one that decides whether ChatGPT cites you is not among them. An r/SEO post from April, 53 points and 40 comments, says Cloudflare quietly cut the author's site off from ChatGPT, from Perplexity and from Google's AI Overviews. I went and read the block. It names ChatGPT's training crawler and not its search crawler, and it never mentions Perplexity at all. The Google agent it does name is one Google says does not affect inclusion or ranking in Search. Take just two of the eight agents. GPTBot governs inclusion in OpenAI's training data, and Google-Extended governs grounding in Gemini Apps. Those are real things to give up. They are not the three things the warning names. What is actually in the file Cloudflare prints the whole block on its managed robots.txt page : # BEGIN Cloudflare Managed content User - Agent : * Content - signal : search = yes , ai - train = no , use = reference Allow : / User - agent : Amazonbot Disallow : / User - agent : Applebot - Extended Disallow : / User - agent : Bytespider Disallow : / User - agent : CCBot Disallow : / User - agent : ClaudeBot Disallow : / User - agent : Google - Extended Disallow : / User - agent : GPTBot Disallow : / User - agent : meta - externalagent Disallow : / # END Cloudflare Managed Content Read that against Cloudflare's own crawler reference table and a pattern falls out. GPTBot is in, OAI-SearchBot is out. ClaudeBot is in, Claude-SearchBot is out. For both of those pairs the table calls the blocked agent an AI Crawler and the one left alone AI Search. Applebot-Extended is in and plain Applebot is not, the same split again. The table has no Applebot-Extended row, so it cannot tell you what Cloudflare calls that one. The block runs along the training and search seam, and that looks deliberate to me. OpenAI's side of it is one line: "Each setting is independent of the others". I worked through the three OpenAI bots and which one governs search visibility in an earlier post , so I will

Originally published on echoeffect.net . If you have been inside Google Search Console recently and clicked into the Pages report (previously called Index Coverage), you may have seen a section titled "Why pages aren't indexed." That list tells you exactly which URLs Google found on your site but chose not to add to its search index, and the reason for each one. This is not abstract SEO theory. Pages that are not indexed cannot rank. If Google is excluding pages from your site, you are losing search visibility you should have, and the reason is usually fixable once you understand what Google is actually telling you. This post covers the four most common "not indexed" statuses small business websites encounter, what each one means in plain terms, and the exact steps to resolve it. A quick note before diving in: Some pages on your site should not be indexed. Thank-you pages, admin pages, internal search result pages, and duplicate filter pages are examples where non-indexing is correct. Before fixing any of these errors, confirm the flagged URL is actually a page you want in Google's index. 1. Page With Redirect What it means: Google followed one of your URLs and landed on a different URL because a redirect was in place. The original URL is not indexed. Only the final destination URL is eligible to be indexed. This status is usually caused by one of three things: Old URLs still listed in your XML sitemap that have since been redirected (common after a site redesign or domain migration) HTTP versions of pages listed in your sitemap when the live site runs on HTTPS Trailing-slash inconsistencies, where your sitemap lists yoursite.com/page but the server redirects to yoursite.com/page/ The redirect itself is not necessarily a problem. A 301 redirect is the correct way to permanently move a page. The issue is that Google's crawler is spending time and crawl budget following chains to find the real URL, and your sitemap or internal links are pointing to the wrong address.

I run a small tech-interview-prep site. It has 8,664 individual pages, one per concept — each with a real question, what it's actually testing, a model answer and the mistake that sinks candidates. Programmatic SEO, the whole playbook. Here's what 28 days of Google Search Console says: Impressions 6,511 Clicks 9 CTR 0.14% Average position 45.9 Pages with at least one impression 1,575 of 8,664 (18%) Nine clicks. In a month. From nearly nine thousand pages. I want to walk through this honestly, because the conclusion I reached is not the one I expected, and it's not the one most posts about programmatic SEO land on. What I assumed was wrong My working theory for weeks was "Google isn't indexing them." That's the standard programmatic-SEO failure story: you publish thousands of pages, Google decides your new domain hasn't earned the crawl budget, and most of them sit in Search Console under Discovered — currently not indexed forever. And early on that was true. A few weeks ago only 6 pages had ever received an impression. It's now 1,575. Google is indexing them, steadily, without me doing anything new. The crawl budget arrived on its own schedule. The clicks did not. The actual failure mode Here's the distribution that explains everything. Across 1,206 distinct queries: Position Share of queries 1–10 12% 11–20 6% 21–50 23% 51+ 59% Median position: 58. That's page six of the search results. Nobody has ever been to page six of the search results. So the pages aren't missing from the index. They're in the index, ranked below anything a human will scroll to. Indexed and invisible are close to the same thing, and the second one is more annoying because the dashboard fills up with numbers that look like progress. 6,511 impressions is real. It's also what position 58 produces: Google shows your result to enough people that you see the impression, and none of them scroll far enough to see it. The queries are the tell These are my top queries by impressions: 11 imp pos 52.2 com

We moved a server-side SEO engine into a Chrome extension. Measuring the page was the easy half. Saying what we could not measure was the hard half. We had been running an on-page analysis engine on our own servers for years. You give it a URL, it fetches the page, it reports. Ordinary. Then we moved that engine into the browser, because a server cannot reach localhost , a staging box, an intranet, or anything behind a login. The browser can. Porting the analysis was mechanical work. What took the real time was a category of problem that barely exists on the server: in a live tab, half the things you want to measure are sometimes unavailable, and the honest answer is not a number. This post is about the decisions that came out of that, with the code that implements them. The One Rule: Null Is Not Zero Every derivation in the engine returns number | null , and the two mean different things. 0 means we measured it and it is zero. A page with no layout shift really does score zero. null means we could not measure it. No interaction happened yet, the browser does not support that entry type, or the document came from another origin and the size fields were zeroed out. A zero printed where a null belongs is a made-up number. It is worse than an empty cell, because the reader has no way to tell it apart from a real measurement. So the two never collapse: the derivation keeps them separate and the UI renders them differently. That sounds obvious written down. It is surprisingly easy to violate, and the next section is the most common way. PerformanceObserver Fails Silently, So Ask It First Here is the trap. Calling observe() with an entry type the browser does not support does not throw . It does not warn. It quietly does nothing, and your handler is simply never called. Which means an unsupported metric produces exactly the same result as a measured zero. The one thing the rule above forbids. The fix is to ask before you observe, and to record the refusal: js const SUPPOR

In mid-July, my Google clicks in my home market (Israel) dropped by almost half. Buyer-intent queries that used to bring steady leads just evaporated from Search Console. While I was staring at GSC dashboards trying to figure out what broke, I finally did the thing I should have done months earlier: I stopped looking at dashboards and started reading raw server logs. What I found there was a parallel universe. Google Search was sending me less than ever — but AI systems were reading my site constantly . Not "someday this will matter" constantly. Right-now constantly: an AI assistant was fetching a page of mine roughly every 26 minutes, around the clock, because a real human had just asked it a question. So I built a small log analyzer and let it run. Here's what 34 days of complete Caddy logs from a small business site (about 70 real human visitors a day) actually look like. The numbers All counts are HTTP 200 responses only (more on why below), over 34 days: Bot Requests Per day What it is bingbot 5,444 158.2 Bing's index — which feeds ChatGPT ChatGPT-User 1,388 40.3 Live fetch while a human asks ChatGPT Googlebot 1,233 35.8 Classic Google crawl GPTBot 547 15.9 OpenAI training crawler Claude-User 519 15.1 Live fetch while a human asks Claude OAI-SearchBot 281 8.2 ChatGPT search indexing Applebot 268 7.8 Apple (Siri / Apple Intelligence) ClaudeBot 214 6.2 Anthropic training crawler Amazonbot 136 4.0 Amazon (Alexa & co.) PerplexityBot 103 3.0 Perplexity indexing Three things in that table genuinely surprised me. ChatGPT-User outreads Googlebot. 40.3 fetches a day versus 35.8. This isn't a crawler building an index for later — ChatGPT-User is the user-agent OpenAI sends when a human is mid-conversation and ChatGPT decides to pull a live page to answer them. On my site, that now happens more often than Googlebot visits. For a tiny business site in a niche market, I did not expect that. Bing crawls 4.4x harder than Google. 158 requests a day versus 36. Nobody optimizes

Ruby Rose Bloom sells one-of-a-kind vintage — a self-hosted storefront, no Shopify, no marketplace underneath it. Search Console's "Merchant opportunities" report told me 3 active products weren't showing up on the Shopping tab, and I went looking for the setting to fix. There wasn't one. What I actually found, three days of digging later, is that "get into Merchant Center" is not one thing — it's several different surfaces, each fed by a different mechanism, and the one everyone talks about (the Shopping tab) turned out to be the least interesting of them. This post is the question I actually had, answered with screenshots taken today: I have a storefront. What does getting into Merchant Center buy me, and where do my products actually end up? It also has an ending I didn't plan. After three days of feed fields and structured data I opened one Search Console report I'd been ignoring and found that Google had indexed 5 of my 436 pages — and, chasing that, that essentially none of my product photos were in the image index either. Those two sections are the most useful thing here, and they're the part I'd read first if I were you. What Merchant Center actually is Before the surfaces: Merchant Center is not an ads product by default. There are two lanes. Free listings are unpaid — you register a feed, Google reviews the items, approved items become eligible to appear in Shopping-related placements at no cost per click. This is the lane a small shop should care about first, because it costs nothing beyond the engineering time to feed it correctly. Shopping ads are the paid lane on top — you attach a budget and the same feed becomes the input to a campaign. Ruby Rose Bloom is running free listings only; there is no ad spend anywhere in this post. Free listings in Merchant Center: approved items, no ad spend, click potential still "available soon" on a three-day-old account. Free listings is the whole story for this shop. Worth saying plainly since most "how to get on Goo

How We Built a 160-Article AI Education Platform with Next.js and Static HTML Three months ago, I launched IAcademy — an AI education platform in Spanish with 160+ free guides covering everything from prompting basics to autonomous agents, LLM deployment, and MCP servers. Here's what worked, what didn't, and the architecture behind it. Why Spanish AI Education is Underserved The AI education space is dominated by English content. Coursera, Udemy, DeepLearning.AI — all English-first. Spanish-speaking professionals (500M+ people) get translated scraps or nothing. The opportunity: 0% competition on keywords like "agentes ia" (400 monthly searches), "herramientas ia" (400), "formación ia" (250). In English, these keywords have 30-50% competition. In Spanish, nobody's writing quality content. Architecture: Why Static HTML, Not a CMS Each blog post is a standalone index.html file. No WordPress, no Gatsby, no MDX compilation step. site/blog/ ├── agentes-ia-que-son/ │ └── index.html ├── herramientas-ia-guia/ │ └── index.html ├── formacion-ia/ │ └── index.html └── ... (160+ directories) Why this approach: Zero build time. Adding an article = creating a directory + file. No compilation, no hydration errors, no framework upgrades breaking 160 pages. Perfect SEO control. Every <title> , <meta> , JSON-LD schema, internal link, and heading hierarchy is hand-crafted per page. No CMS template imposing its structure. Instant deploy. Push to GitHub → Cloudflare Pages deploys in ~30 seconds. No build queue. No JavaScript required for content. Google indexes immediately. Core Web Vitals are perfect — there's nothing to load. The dynamic parts (auth, course portal, labs) use Supabase + vanilla JS. But the blog — which is the SEO engine — is pure static HTML. Content Strategy: Niche Prompts Beat Head Terms After 3 months, here's what ranks and what doesn't: What ranks (top 10 in Google): prompts-ia-facturacion — prompts for accountants (position 8.4) prompts-ia-logistica — prompts for lo

Three weeks ago a page that had been pulling steady search traffic for over a year disappeared from Google. Not deranked, just gone. I only noticed by accident, about ten days later, while poking around Search Console for something unrelated. Ten days of a page earning nothing because nobody, including me, was watching. Some background: I'm a marketer. I run a small agency, I publish a lot of pages across a few sites, and my technical ceiling for the last decade has been editing HTML that someone else wrote. Our actual developers are busy with actual work, and "can you build me a thing that watches Google" is exactly the kind of request that dies in a backlog. Search Console does show you indexing problems. It shows them to people who log in and go looking. I have around 400 URLs I care about across three properties, and I was never going to check them by hand on any schedule more honest than "when something feels off." I'd been reading Claude Code posts on here for months as a spectator. The genre is usually a developer using it to move faster. I wanted to know what happens when someone who can't write the code at all uses it to start from zero. So I paid for a month and typed what I wanted in plain English. Version one lasted twenty minutes My first prompt was something like: check if these URLs are indexed in Google and tell me when one falls out. Claude cheerfully produced a script that ran a site: search for every URL and scraped the results page. It worked. For about twenty minutes. Then Google decided I was a robot, which was technically correct, and started serving captchas. Nobody warned me about this part of vibe coding: the model will build exactly what you asked for, including when what you asked for is against the rules and dies on contact with reality. It only mentioned that scraping Google results is a bad idea after I pasted the captcha error and asked why everything was broken. Then it apologized and told me what it could have said at the start: the

Small business websites rarely fail because of one catastrophic bug. They fail from an accumulation of small, fixable problems — a slow hero image here, an unlabeled form field there, a broken tab order that quietly locks out keyboard users. None of it looks dramatic in a screenshot. All of it adds up to lost conversions. Working across client rebuilds and audits at Alynox, the same handful of issues show up repeatedly, regardless of industry. Here are ten of the most common, with the practical, mostly low-effort fixes that address them. Unoptimized Images Dragging Down Load Time The single most common performance killer on small business sites is still oversized images — a 4MB PNG hero banner exported straight from a design tool, served at full resolution to a phone screen 400px wide. Fix: html src="hero-800.webp" srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w" sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1600px" alt="Interior of the workshop showing custom furniture in progress" loading="lazy" width="1600" height="900" /> Convert to WebP or AVIF, generate a handful of responsive sizes, lazy-load anything below the fold, and always set explicit width/height to reserve space and avoid layout shift. No Real Mobile-First Design A lot of "responsive" small business sites are really desktop layouts that get squeezed with media queries until they technically fit a phone screen. Buttons end up too small to tap accurately, text wraps awkwardly, and nav menus overlap content. Fix: Design and build mobile-first — base styles for small screens, then progressively enhance with min-width media queries for larger viewports: css .card { padding: 1rem; } @media (min-width: 768px) { .card { padding: 2rem; } } Tap targets should be at least 44×44px (per WCAG and Apple/Google HIG guidance), with enough spacing between interactive elements to prevent mis-taps on smaller screens. Accessibility Treated as an Afterthought Missing alt text, low-contras

I built 109 tools that never touch a server - here is the architecture Most "tools" sites you have used do this: You upload a file It goes to a server The server processes it You download the result Sometimes the server stores it. Sometimes it leaks. Sometimes it disappears with the company. I wanted something different. Every tool on korelyy.com runs 100% in your browser . Zero backend. Zero upload. Zero tracking. Here is the actual architecture, the real numbers after 90 days, and what I learned. What "no server" actually means For each of the 109 tools: The entire app is a static HTML + CSS + JS file It is served as-is from a CDN (Cloudflare Pages) All file processing happens in your browser via FileReader , canvas , Web Crypto API , or OffscreenCanvas Your file never leaves your device Closing the tab = the data is gone (no cookies, no localStorage, no account) This is not a marketing claim. It is verifiable: Open DevTools -> Network tab Use any tool that requires a file (image converter, JSON formatter, etc.) Reload. The only network request is for the static HTML/CSS/JS bundle. No fetch() to a server. No XHR . No upload. The file is read, processed in-memory, and downloaded. The 4 browser APIs that do 90% of the work When you remove a backend, you are left with the browser. The browser is more capable than most people think. 1. FileReader and URL.createObjectURL Read any file the user gives you: const file = document . querySelector ( ' input[type=file] ' ). files [ 0 ]; const url = URL . createObjectURL ( file ); const img = new Image (); img . onload = () => { // process image canvas . toBlob ( blob => { const downloadUrl = URL . createObjectURL ( blob ); // trigger download }); }; img . src = url ; Image conversion, PDF generation, audio trimming - all the same pattern. Read blob, process, create new blob, download. 2. crypto.subtle (Web Crypto API) Hashing, encryption, signing - all client-side: const hash = await crypto . subtle . digest ( ' SHA-256 ' , a

WordPress sitelerinde hız problemi yaşandığında genellikle ilk refleks bir cache eklentisi kurmak oluyor. Bazen gerçekten fark yaratıyor, bazen de PageSpeed puanı biraz yükselmesine rağmen site hâlâ yavaş hissettiriyor. Bunun nedeni WordPress performansının tek bir ayardan oluşmaması. Hosting, tema, eklentiler, görseller, JavaScript dosyaları ve veritabanı aynı anda sayfanın yüklenme süresini etkileyebiliyor. Bu nedenle bir siteyi hızlandırmaya başlamadan önce asıl problemin nerede olduğunu bulmak gerekiyor. WordPress projelerinde sık karşılaştığım 7 performans hatasını aşağıda topladım. Gereğinden büyük görseller kullanmak En sık karşılaştığım problemlerden biri bu. Sayfada 700 piksel genişliğinde görüntülenecek bir görselin 4000-5000 piksel olarak yüklenmesi oldukça yaygın. Özellikle yüksek çözünürlüklü stok fotoğraflar doğrudan WordPress'e yüklendiğinde tek bir görsel birkaç megabayta ulaşabiliyor. Bu da özellikle mobil bağlantılarda ciddi yük oluşturuyor. Görselleri yüklemeden önce kullanılacağı alana uygun boyuta getirmek, sıkıştırmak ve mümkün olduğunda WebP veya AVIF gibi modern formatları tercih etmek önemli. Ancak yalnızca dosya formatını değiştirmek yeterli değil. 4000 piksel genişliğindeki bir görseli WebP'ye çevirmek, görselin gereğinden büyük olduğu gerçeğini değiştirmiyor. Her problemi cache eklentisiyle çözmeye çalışmak Cache WordPress performansında önemli bir yere sahip. Fakat cache eklentisi kurmak her hız problemini ortadan kaldırmaz. Sunucu geç cevap veriyorsa, çok fazla JavaScript çalışıyorsa veya veritabanında ağır sorgular varsa cache yalnızca problemin bir bölümünü gizleyebilir. Ayrıca aynı anda birden fazla optimizasyon eklentisi kullanmak da başka sorunlara yol açabiliyor. Örneğin bir eklentide JavaScript erteleme, başka bir eklentide tekrar JavaScript optimizasyonu ve hosting panelinde üçüncü bir optimizasyon sistemi açıldığında hangi ayarın ne yaptığını takip etmek zorlaşıyor. Ben mümkün olduğunca tek bir ana cache sistemi üzerinden ilerl

Type a question into Google right now and there's a decent chance you never leave the search page. The answer sits right there, generated on the spot, with maybe two or three source links tucked into the bottom of it. Ten blue links used to compete for a click. Now one paragraph competes for a citation. That shift matters more than most content advice has caught up with. Ranking on page one used to be the finish line. Increasingly, the finish line is getting pulled into an answer that someone reads and never clicks through from at all. And getting pulled into that answer takes a different kind of writing than getting ranked ever did. What Google Actually Rewarded For twenty years, ranking well meant reverse-engineering an algorithm that was trying to guess what a human typed and wanted. That produced a specific kind of writing, one built around keyword placement and phrasing that matched whatever a person typed into the box. Length mattered too, since word count signaled thoroughness to an algorithm even when the extra words were just padding. None of that was really about the words themselves. It was about satisfying a system that stood between the writer and the reader, on the assumption that satisfying the system was the only way to reach the reader at all. What AI Systems Do Instead An AI answer engine isn't ranking pages. It's extracting claims. It reads through a pile of sources, pulls out the sentences that most directly answer the question, and stitches them into a response. Nobody scrolls past that response to see where it came from unless they specifically want to check. That changes what counts as good writing in a fairly specific way. A sentence that gets pulled out of a paragraph and dropped into someone else's answer either holds up on its own or it doesn't. If a claim only makes sense next to the three sentences before it, it never gets picked. If it depends on a "however" two paragraphs earlier to be accurate, it gets misquoted or skipped entirely. W