SEO for programmers: what search engines actually want — and the tricks I’d stop doing

I write software for a living and I have also shipped pages that needed to rank. The SEO I was sold in 2014 was a bag of tricks: density, exact-match domains, a footer of links. The SEO I would do in 2026 as a programmer is closer to making a document the crawler can fetch and a human can finish. Search engines want that document to answer the query and to stay fetchable. They do not want my cleverness. Here is what I still do, and the tricks I would stop even if a thread swears they still work.

What the engine actually wants from a page I wrote

A crawlable URL. If the article lives behind a client-only route with no HTML, I have written a secret. I have shipped Next.js apps that needed a server render or a static path so the title and the first paragraphs exist in the first response. View-source is still a test. If view-source is empty, I do not argue with Search Console. I fix the render.

A title and H1 that match the job. Not a pun that hides the product. I like a title that a tired person would type. “sqlc vs Hibernate for a Go billing API” beats “Rethinking persistence in the modern era.” I have written both. Only one got the click from a person who had the problem.

A page that is the answer, not a doorway. Thin posts that exist to host an affiliate table are the trick I would stop. If I cannot add a failure I have seen, I do not publish. The engine is noisy and still better than it was at smelling a doorway. I am also better at smelling my own.

Internal links that are the next question, not a footer of “related.” I have a house rule for this site. I follow it. A programmer who sprinkles twelve links because a spreadsheet said “2–6 per hub” is doing 2016. One honest link is a service. A cluster dump is a trick.

Technical SEO I will still ship before another post

Canonical tags when I have parameters or a trailing-slash mess. I have seen a site compete with itself. The engine picked the worse URL. I pick one and I 301 the rest.

A sitemap that only lists URLs I want crawled, and a robots.txt that is not a museum of Disallow I forgot. I have blocked /blog by accident. I have also left a staging site open. Both are programmer errors. I check them like I check env files.

Core Web Vitals as a budget, not as a religion. I will not ship a 400KB hydrate to a docs page. I will not chase 100 Lighthouse on a dashboard that is an app. The document-shaped pages — docs, blog, marketing — get the cheap HTML. The app gets an app. Mixing them is how a blog inherits a SPA tax.

Structured data when it is true: Article, FAQ only if the FAQ is on the page, SoftwareApplication if I actually have software. I will not invent reviews. I have seen that go badly for people who are not me. I do not need that story.

hreflang only if I truly have locales. Fake locales are a trick. One good English page beats three thin translations.

HTTPS, a working 404, no index on thank-you pages and search-result pages on my own site. I have indexed a faceted crawl and watched the engine waste budget. I now noindex the combinations I will not stand behind.

The tricks I would stop

Keyword stuffing and the synonym salad in the first paragraph. I will use the words a searcher uses. I will not repeat them until the paragraph is unreadable. The ranker is not a child.

Exact-match guest posts on expired domains. Link schemes. PBNs. I have been offered these. I have declined. The risk is a site I cannot explain to a future buyer, and a penalty I cannot debug like a 500.

Cloaking: a different page for the bot. This is not “prerender for JS.” This is a bait title. I will prerender so the bot sees the same article. I will not swap the article.

Auto-generated pages for every city and every SKU with three words changed. Programmers love a loop. The engine has seen the loop. I generate a page when the page has a unique constraint — a real city office, a real SKU with a real spec. Otherwise I use filters and I noindex the junk.

Buying traffic that I then call “organic” in a slide. That is not SEO. That is a category error I have watched startups make.

Programmer habits that accidentally help

A changelog that is a page, not a tweet. People search version errors. I have ranked for “Meilisearch distinct attribute” because I wrote the sentence the error produced.

Status codes that match reality. A soft 404 that returns 200 is a crawl tax and a user lie. I return 404. I return 410 when I mean gone. I do not invent 200 for an empty filter.

Logs. I read Search Console the way I read Sentry: not daily as a personality, but when I ship a batch and when a page I care about drops. I do not refresh it like a slot machine. I do not rewrite a good page because impressions dipped for a week.

I write the meta description like a commit message for humans: what you will get, not a keyword list. I set a focus phrase so I do not wander. I do not write for the phrase until the article is false.

AI text and the new trick I will not run

I use models to outline and to argue with. I do not publish a page I have not sat with. The engine is already drowning in fluent emptiness. Adding to that pile is a trick that looks like leverage and feels like spam from the inside. If the article does not contain a decision I have made, I delete the draft. That is the only filter I trust.

I also do not hide AI as a strategy to “scale content.” Scaling content is how you become a doorway site with a nicer CMS. I would rather have fifty pages I can defend than five hundred I cannot read.

What I do with Search Console without becoming a servant

I look at queries that already show the page at position 8–20 with impressions. Those are the ones I will tighten: a clearer H2, a paragraph that names the product, a title that matches the query I am already almost winning. I do not invent ten new posts for a vanity keyword at position 80. That is a content factory. I have better things to compile.

I export a few queries and I ask: would I be angry if this page was the result? If yes, I fix the page or I noindex it. Ranking for a query you cannot satisfy is a trick that creates bounce and a reputation I do not want in the logs.

I do not chase every algorithm rumor. I ship the fetchable document and I wait. Programmers want a deploy to be the fix. SEO is slower than CI. I schedule the check like I schedule a restore drill: after a batch, not after every paragraph.

A checklist I run before I hit publish

1. View-source shows the title, the H1, and two real paragraphs.
2. The URL is stable and boring. I will not rename it for a pun later.
3. Images have alt that describes the picture. They are not keyword bags.
4. One canonical. No accidental noindex on the live article.
5. A sitemap ping or a next crawl I can live with. I do not demand indexation overnight.
6. The page answers a query I would type. If I cannot name the query, I am writing a journal. Journals can be fine. They are not SEO.

Search engines want a fetchable document that satisfies the query and does not waste the crawl. The tricks I would stop are the ones that try to look like that document without being it. The programmer job is to make the being cheap: render HTML, status codes, a title that tells the truth, a site that does not fight itself. I will take that over a density plugin. I have used the plugin. I have also used view-source. Only one of them still helps after a core update. I will keep writing pages that contain a decision. I will keep the HTML honest. I will stop treating SEO as a layer I sprinkle on after the article exists. The article is the SEO. Everything else is plumbing so the crawler can agree. I will keep view-source as my first test. I will keep the tricks in the past tense. That is the whole practice I can still defend after a core update and a bad week of impressions.