DEV Community: Emir Baycan

We stopped paying $100+/mo for SEO tools. Here's the technical-audit setup we use instead

Emir Baycan — Sun, 07 Jun 2026 21:12:19 +0000

We run 10+ web products. For years our SEO tooling was a $100+/month subscription we mostly used for one job: technical audits. The keyword and backlink dashboards sat untouched while the bill renewed every month. At some point the math stopped making sense, so we rebuilt our stack around what we actually use. Here's the honest breakdown — what we kept free, what we replaced, and why.

What a technical audit actually needs to check

Before picking tools, it helps to know what you're auditing. The technical layer is finite and well-defined:

Crawlability — robots.txt, broken internal links, redirect chains
Indexability — noindex tags, canonical correctness, soft 404s, orphan pages
Sitemaps — only canonical, indexable, 200-status URLs
On-page — titles, meta descriptions, one H1, valid structured data
International — hreflang reciprocity (if you're multilingual)
Performance — Core Web Vitals (LCP, CLS, INP)

That's it. None of it requires a keyword database or a backlink index — the two things you're really paying $100+/mo for in the big suites.

The free tools that cover most of it

Google Search Console is non-negotiable and free. The Pages report is the source of truth for what's indexed and why the rest isn't. PageSpeed Insights (free) gives you real Core Web Vitals. Screaming Frog's free tier crawls up to 500 URLs, which is plenty for small sites.

For a long time that was our whole stack: GSC + PageSpeed + free Screaming Frog. If your site is under 500 pages, you may not need anything else.

Where it broke down for us

The free Screaming Frog cap (500 URLs) is the wall. Several of our sites are bigger, and re-auditing them meant either the paid Screaming Frog licence (annual) or going back to a monthly suite. Both felt wrong for something we run after every deploy.

So we built our own crawler for the technical layer — and then, honestly, turned it into a product because other people we talked to had the same problem. It does the whole checklist above across the entire site, plus PageSpeed, with one-time pricing instead of a subscription ($9-49, credits never expire). It's the same engine we run on our own properties — kalenux.com.tr/seo, and there's a free no-signup check if you want to see what it flags. It is not a keyword tool — we still use a separate (cheaper) option for that.

The actual takeaway

The point isn't our tool — it's the unbundling. Most people pay for a full SEO suite to use 20% of it. Split the jobs:

Technical audits → a dedicated crawler (free tier, a one-time tool, or paid Screaming Frog)
Keyword research → a cheaper standalone option, or free ones
Backlinks → only if you genuinely work on link-building

Most small sites and freelancers can cover everything they actually use for a fraction of a single suite subscription. We went from $100+/mo to a few dollars a year on the technical side, with no loss in what we could check.

Written by the Kalenux team.

I built 9 free SEO tools so I'd stop paying $100/mo to audit my own sites

Emir Baycan — Sun, 07 Jun 2026 20:05:54 +0000

We run 10+ web products. For years we paid for an SEO suite mostly to do one thing: technical audits. The keyword and backlink features sat unused while the bill renewed every month. So we built our own technical-audit engine — and then split the individual checks out into free, no-signup tools. Here's what each one does and the technical reasoning behind it.

All of them run an instant check on a URL with no account. Try them on your own site as you read.

The crawlability & indexing tools

Indexability Checker — the most important one. A page that isn't indexable can't rank, full stop. It checks for noindex tags, robots.txt blocks, canonical conflicts and non-200 status. The classic outage we've all caused: a stray noindex on a shared layout that ships to production and quietly deindexes a whole section.

Canonical Checker — verifies rel=canonical is self-referencing and resolves to a live 200. The subtle bug it catches: a canonical pointing at a URL that then redirects. Google ignores those and picks its own canonical, so your signal is wasted. Common after an HTTP→HTTPS migration where canonicals weren't updated.

Sitemap Validator — locates your sitemap (via robots.txt or /sitemap.xml), validates the XML, counts URLs, checks HTTPS consistency, and samples a few URLs for live 200 status. A sitemap full of redirected or 404 URLs sends mixed signals and wastes crawl budget.

Technical SEO Checker — the full crawl-based audit across every page, not just the homepage.

The on-page tools

Meta Tag Checker — title, meta description, canonical, viewport and Open Graph tags, checked for presence and length. Title truncates around 60 chars; meta description around 160.

Broken Link Checker — finds broken internal and outbound links plus redirect chains, with the source pages for each. Fixing broken links is the highest-return, lowest-effort technical task there is.

Hreflang Checker — for multilingual sites. Hreflang is the most error-prone area of technical SEO: it needs reciprocal return tags, a self-reference, valid language codes, and targets that return 200. Miss any and Google ignores the whole cluster.

Performance

PageSpeed Test — real Core Web Vitals (LCP, CLS, INP) on your key templates, mobile and desktop. Test a product or category page, not just the homepage — those carry the traffic and usually score worst.

Why free, why no signup

The instant checks read one page (your homepage) and need no account, because the fastest way to show a tool is useful is to just let people use it. The full site-wide crawl is the paid product, but it's one-time pricing ($9-49, credits never expire) rather than a subscription — which was the whole point of building it. We were tired of paying monthly to re-audit our own properties.

If you maintain your own sites, the full toolbox lives at kalenux.com.tr/seo-tools. And if you just want the methodology, the complete technical SEO audit guide walks through the whole process in order.

Written by the Kalenux team.

8 ways your site quietly deindexes itself (and how to catch them)

Emir Baycan — Fri, 05 Jun 2026 17:46:01 +0000

Deindexing is the quietest way to lose traffic. Nothing 404s, nothing looks broken - pages just slip out of Google's index and the rankings go with them. We run 10+ web products and these are the eight causes we see over and over. Each one is invisible until you go looking.

1. A stray `noindex` on a shared template

The classic. Someone adds <meta name="robots" content="noindex"> to a layout or component to hide a staging page, and it ships to a template used by hundreds of pages. Whole sections vanish from search.

Catch it: grep your built output for noindex. It should only appear where you genuinely want it (thank-you pages, internal search results). Anything else is a leak.

2. Canonical tags pointing to the wrong URL

If page A says <link rel="canonical" href="B">, you're telling Google "index B instead of me." Get this wrong across a template - e.g. every paginated page canonicalising to page 1 - and you deindex pages 2+.

Catch it: every page should self-reference its canonical unless you have a deliberate reason not to. Watch especially for canonicals pointing to a redirect or a 404 - Google ignores those and picks its own, unpredictably.

3. robots.txt blocking what you want indexed

A Disallow: rule meant for one folder can match more than you think. And blocking a URL in robots.txt doesn't deindex it - it just stops Google re-crawling, so a page can stay indexed with no snippet, or get stuck.

Catch it: test your important paths against your robots.txt rules. Make sure your sitemap is declared with a Sitemap: line too.

4. Non-canonical or redirected URLs in your sitemap

Your sitemap is a list of "please index these." If it's full of redirected URLs, non-canonical variants, or 404s, you send mixed signals and waste crawl budget.

Catch it: your sitemap should contain only canonical, indexable, 200-status URLs. Audit it.

5. Soft 404s

A page returns HTTP 200 but has no real content ("No results found", an empty category). Google calls these soft 404s and quietly drops them - or worse, loses trust in that section.

Catch it: thin/empty pages that return 200 are the tell. Either add content, noindex them deliberately, or return a real 404.

6. Redirect chains and loops

A -> B -> C -> D wastes crawl budget and dilutes signals at every hop. A redirect loop (A -> B -> A) is worse - Google gives up.

Catch it: collapse every chain to a single hop. A -> D, done.

7. Canonical-to-redirect

A subtle one: page A canonicalises to B, but B redirects to C. Now your canonical signal is broken and Google has to guess. This commonly happens after an HTTP-to-HTTPS or trailing-slash migration where canonicals weren't updated.

Catch it: make sure every canonical target returns 200 directly, not a redirect.

8. Orphan pages

A page with zero internal links pointing to it. Google can technically find it via the sitemap, but with no internal links it reads as low-priority and often won't get or keep an index slot.

Catch it: build your internal link graph and find pages with zero incoming links. One warning from experience: if your crawler times out while resolving the link graph, it will report every page as an orphan. Make sure the incoming-link count actually computed before you trust it - a false "everything is orphaned" result has sent people chasing ghosts.

How to monitor this without a $100/mo suite

Google Search Console -> Pages report is the source of truth: it tells you exactly what's indexed and, for everything that isn't, why. Free. Check it weekly.
Screaming Frog free tier crawls 500 URLs and surfaces most of the above for small sites.
For site-wide crawls without the subscription, we built our own (Kalenux SEO Audit) - it flags noindex, canonical errors, soft 404s, redirect chains, sitemap mismatches and orphans across the whole site, one-time pricing instead of a monthly bill. It's the technical-audit piece only, not a keyword tool.

Deindexing is sneaky precisely because nothing looks broken. Set up the monitoring, run a crawl after every deploy that touches templates or redirects, and you'll catch these before they cost you a quarter of rankings.

The technical SEO audit checklist we run on every site (no $100/mo tool needed)

Emir Baycan — Fri, 05 Jun 2026 12:17:34 +0000

We maintain 10+ web products, and before any of them ships content we run the same technical SEO pass. None of it requires an expensive suite - most of it is free if you know where to look. Here's the exact checklist, grouped so you fix root causes once instead of chasing symptoms.

1. Crawlability and indexability (fix these first)

Nothing else matters if Google can't crawl or index the page.

robots.txt - make sure you're not accidentally Disallow-ing important paths, and that your sitemap is declared with a Sitemap: line.
Noindex tags - search your templates for stray noindex. A single misplaced meta tag on a layout file can deindex a whole section.
Canonicals - every page should have a self-referencing canonical unless it's deliberately pointing elsewhere. Watch for canonicals that point to a redirect or a 404 - Google ignores those and picks its own.
Sitemap hygiene - your sitemap should only contain canonical, indexable, 200-status URLs.

Quick check: in Google Search Console, the Pages report tells you exactly what's indexed and why the rest isn't. It's free and it's the source of truth.

2. Links and redirects

Broken links waste crawl budget and leak authority.

Broken internal links (404s) - fix or remove them.
Redirect chains - A -> B -> C should be A -> C. Every hop loses a little authority.
Broken redirects - a redirect that lands on a 404 is worse than no redirect.
Orphan pages - pages with zero internal links pointing to them. (Careful detecting these: if your crawler times out building the link graph, it'll report every page as an orphan. Make sure your incoming-link count actually resolved before trusting it.)

3. On-page basics that still move rankings

Unglamorous, still effective.

Titles - unique, descriptive, not truncated. Flag missing, duplicate, too-long, too-short.
Meta descriptions - same treatment. They don't directly rank you but they drive click-through.
One H1 per page, with a sane heading hierarchy (H1 -> H2 -> H3, no skipping straight to H3).
Structured data - if you use JSON-LD, validate it. Invalid schema can throw errors in Search Console and block rich results. A common one: putting aggregateRating on an object type that doesn't support it.

4. International (if you have it)

Hreflang is the single most error-prone area of technical SEO.

Every hreflang annotation needs a reciprocal return tag.
Include a self-referencing hreflang.
Don't point hreflang at redirected or broken URLs.
Make sure html lang matches the hreflang you're claiming.

5. PageSpeed and Core Web Vitals

Real-world performance, not lab vanity numbers.

Run PageSpeed Insights on your key templates (home, a product/post page, a category page).
Watch LCP, CLS, INP. Common wins: compress images, add font-display: swap, defer render-blocking JS/CSS, serve assets gzipped/brotli.

How to run this without paying $100+/month

You can cover a lot for free:

Google Search Console + PageSpeed Insights - free, authoritative, have them regardless.
Screaming Frog free tier - crawls up to 500 URLs, great for small sites.
For site-wide crawls on bigger sites without the subscription, we built our own tool (Kalenux SEO Audit) because we were tired of paying monthly just to re-audit our own properties - it runs the whole checklist above plus PageSpeed from the browser, one-time pricing instead of a sub. It's the technical-audit piece only, not a keyword suite, so pair it with whatever you use for keyword research.

The point isn't the tool. 80% of technical SEO problems come from this short list, and you can catch almost all of them without an enterprise subscription. Run the checklist, fix root causes, re-crawl, and move on.

Why we built our own Node.js website build system

Emir Baycan — Wed, 03 Jun 2026 12:42:11 +0000

Across our portfolio at Kalenux, most pages are content: articles, guides, localized variants, category pages. They change when we publish, not on every request. So instead of rendering them per-request, we treat building the site as a step that runs when content changes — and we built our own tool to do it.

That tool is Kalenuxer, our open-source, Node.js-based website build system. Here is why it exists and what it does.

Why build our own

We tried existing static-site generators. Each did part of what we needed, none did all of it — fast incremental builds, real multilingual support, and automated deployment, together, across many large sites. So we built one in-house.

It is written in Node.js because the team lives in JavaScript and TypeScript daily, the ecosystem for parsing, templating, and asset handling is deep, and it keeps the build tooling in the same language as much of our frontend work.

Incremental builds

The feature that matters most at scale: Kalenuxer only rebuilds what changed. CSS, JS, and HTML are tracked separately with timestamp-based invalidation. Edit one article and you rebuild one page, not the whole site.

On a site with thousands of pages, that is the difference between a build measured in minutes and one measured in seconds. When you publish often, that compounds into real time saved every day.

Multilingual by default

Our content products run in 15+ languages. Kalenuxer has i18n built in: JSON data files per language, no external translation service or third-party dependency. Adding a language is adding a data file, not re-architecting the site.

Template-based, automated deploy

Pages are composed from templates, so structure stays consistent across a product and changes propagate cleanly. Deployment is automated off the build, so shipping content is not a manual ritual.

The point

Kalenuxer is not the product — it is the tooling that lets a focused team ship and maintain 10+ live products without the build process becoming the bottleneck. Sometimes the highest-leverage thing you can build is the thing that builds everything else.

Software that works. Products that last.

Kalenux is a software powerhouse from Istanbul building web and mobile products at scale, and the open-source Kalenuxer build system. Founded and led by Emir Baycan. kalenux.com.tr

Build and operate: why running your own software changes how you engineer it

Emir Baycan — Sun, 31 May 2026 13:28:33 +0000

A lot of software is built to be handed off. A team ships it, signs off, and moves on. At Kalenux we don't hand off — we build our products, then we run them in production for the long haul. That single choice changes how the whole team engineers.

You optimize for the next two years, not the demo

When the finish line is a handoff, you optimize for the moment of delivery: it looks done, it passes review, it ships. When you know your team will still be running this in two years, the incentives invert. You optimize for the day a dependency breaks, the week traffic spikes, the month someone needs to change code written long ago.

"Done" stops meaning "shipped" and starts meaning "still good a year from now" — across 10+ products and 500,000+ users who notice when something breaks.

You feel your own decisions

Operating your own software creates a feedback loop a build-and-handoff shop never gets:

Slow builds? The team feels them on every publish — which is exactly why we built our own incremental build system.
Painful localization? We run products in 15+ languages, so the tooling has to handle it cleanly, not heroically.
Sloppy output? It shows up in our own search results and our own support load, so correctness gets built in, not bolted on.

Nobody files a ticket about these. The people who feel the pain are the people who fix the cause.

Specialists, not generalists spread thin

Our products lead their categories because they are built by people who understand the domain — engineers, domain researchers, and product specialists, not a generic feature factory. A privacy-first file converter is built by people who care about client-side guarantees; a cognitive assessment is built with input from researchers. Depth is the point.

Build and operate is a discipline

It is easy to say you care about quality. Operating your own software forces it: you can't walk away from a shortcut, it waits for you in production. So you stop taking it.