SEO for Product Engineers: What Actually Moved the Needle for Our Platform

We are engineers, not SEO consultants. When we built Gigai Tools — our platform of 248+ free, browser-based tools at tools.gigaikripaservices.com — we assumed good software would find its own audience. It did not. A tool nobody can find is functionally identical to a tool that does not exist, and search engines do not award points for clean code.

So we treated discoverability the way we treat any other system: define the architecture, instrument it, ship in small increments, keep a changelog, delete what does not work. Over several build cycles that approach produced a small set of practices that measurably mattered — and a longer list of "standard SEO advice" that we abandoned because it never did anything for us.

This is the honest version of that list, written for people who ship product rather than people who sell SEO retainers.

Internal linking is architecture, not a content chore

The single highest-leverage change we made was refusing to hand-place internal links. With 248 tools, manual linking guarantees two things: orphan pages and stale links. Instead we built the relationships into the data model. Every tool declares its category, the file formats it accepts and emits, and the tasks it belongs to. An internal-linking engine renders "related tools" from that graph, so when we ship tool number 249 the links to and from it exist on deploy day, automatically.

On top of the graph we added task hubs — pages organised around what a user is trying to do ("clean up a PDF", "generate QR codes for a campaign") rather than around our category taxonomy. Hubs matter because they match query intent. Nobody searches for your navigation structure; they search for their problem. Each hub links down to the specific tools, and each tool links back up, which gives crawlers short paths to everything and gives users an obvious next step.

The rule we now apply to every feature: if a page can only be reached through the nav menu or a sitemap, it is an orphan in practice. Every page needs at least three contextual inbound links from pages that make sense, and those links must be generated, not remembered.

One rich page beats fourteen thin URLs

Early on we faced the classic programmatic-SEO temptation. A QR code generator can plausibly justify separate URLs for "QR code for WiFi", "QR code for vCard", "QR code for payments" and a dozen more. Fourteen keywords, fourteen URLs — the spreadsheet logic is seductive, and half the SEO industry will tell you to do it.

We deliberately chose the opposite: one rich page per real capability, with deep sections covering each use case, and a jump navigation so users and crawlers can land directly on the relevant section. The thin-URL approach fails for a reason engineers will recognise instantly: it is copy-paste duplication at the page level. The variants cannibalise each other, none of them accumulates enough substance to rank on merit, and you now maintain fourteen near-identical pages forever.

The rich-page approach concentrates everything — content depth, internal links, whatever authority the page earns — onto a single URL. When we built our 36 QR tools we still shipped separate tools where the functionality genuinely differed, because a WiFi QR generator and a bulk QR generator are different software. The test is simple: if two pages would share the same code, they should share the same URL.

Answer-first content, because the reader is often a machine now

A growing share of our audience never sees our pages directly. AI assistants and AI-augmented search results read the page, extract an answer, and present it. That changed how we write more than any classic ranking factor did.

Every tool page now opens with a direct answer block: what the tool does, what goes in, what comes out, and the one fact that differentiates it — in our case, that files are processed entirely in the browser and never leave the device. No throat-clearing, no "in today's fast-paced world", no three paragraphs of preamble before the point. If a language model quotes only the first ninety words of your page, those ninety words should be a complete, accurate answer.

Below the answer block we go deep: edge cases, honest limitations, format quirks. Depth still matters for humans who scroll. But the inverted pyramid is no longer a journalism affectation; it is a technical requirement of how content gets consumed.

One uncomfortable corollary: honesty became a ranking asset. We state limits plainly — file size ceilings, formats we do not handle, browsers where a feature degrades. Machine readers extract those statements verbatim, and a user who arrives pre-warned converts better than one who arrives misled.

Structured data that earns something, and the schema we skipped

Structured data has terrible signal-to-noise. Most schema types you can add will validate perfectly and change nothing. We now add schema only where a concrete rich result or machine-readability win exists.

• SoftwareApplication on every tool page, with price set to zero — it accurately describes what the page is and helps aggregators classify free tools correctly.
• FAQPage only where the questions are real ones users ask, written as genuine answers rather than keyword vehicles.
• BreadcrumbList everywhere, generated from the same category graph that drives internal linking — one source of truth, two outputs.
• HowTo only on pages with an actual multi-step procedure; slapping it on a single-step tool is noise.

What we skipped: review and rating schema without real reviews (an invitation for a manual action), Organization schema stuffed with keywords, and speculative schema types with no documented result. Generate all of it from templates fed by your data model. Hand-written JSON-LD drifts out of sync with the page within a month, and inconsistent schema is worse than none.

What we stopped doing because it never worked

• Publishing thin "what is X" blog posts to target keywords. They ranked for nothing, attracted nobody, and diluted the site. We deleted them.
• Chasing exact-match keyword variants with near-duplicate pages — see the fourteen-URL story above.
• Rewriting meta descriptions in pursuit of click-through magic. A clear, accurate sentence performs the same as an agonised-over one; Google rewrites half of them anyway.
• Directory submissions and reciprocal link swaps. Hours spent, zero measurable effect.
• Waiting for content to be "comprehensive" before shipping. A good page live for six months beats a perfect page live for one.

The pattern in every failure: activity that produced pages or links without producing anything a user would actually want. Search engines have become depressingly competent at detecting exactly that.

Run SEO like a system, not a campaign

The meta-lesson is that everything which worked was structural, and everything which failed was cosmetic. Internal linking worked because it lives in the data model. Answer-first content worked because it is a template constraint, enforced on every page equally. Schema worked because it is generated, not hand-authored. We even keep a public changelog for the platform, partly because shipping visibly is itself a trust signal, and partly because a changelog forces the discipline of small, dated, verifiable improvements.

If you are an engineer who has been told SEO is marketing's job, our experience says otherwise. The levers that moved for us — information architecture, structured data generation, content templates, crawl paths — are all things only the people who own the codebase can pull properly. Treat your site's discoverability as a subsystem with an owner, a data model and a test suite, and it responds the way well-built systems do: predictably, and compounding over time.