Editorial Policy

Last updated:

Plain-language summary: every article here is grounded in a named, citable source and checked against the official documentation before publication, and it is updated when the upstream API changes. Where a fix has been reproduced end to end on a live environment, the run is published with it. Affiliate relationships do not influence what we write.

1. What we cover

Iloveblogs.blog is a technical blog covering production-grade patterns for JavaScript/TypeScript developers. Our three main pillars are:

  • Next.js — App Router, Server Components, edge runtime, caching, ISR.
  • Supabase / PostgreSQL — Auth, Row Level Security, migrations, realtime.
  • n8n automation — workflows paired with LLMs (mostly Ollama for local inference).

Anything outside these pillars is excluded from the sitemap and marked noindex; see our OFF_TOPIC_SLUGS list in the source code for the up-to-date exclusions.

2. Sourcing

Every published article must be backed by at least one real, citable source:

  • Official documentation — Next.js docs, Supabase docs, MDN, the docs of the specific library being discussed.
  • Maintainer / spec sources — GitHub issues, releases, RFCs, changelogs.
  • Search Console evidence — queries with real impressions and clicks when we're working on something already showing demand.
  • High-signal community evidence — Stack Overflow questions with a confirmed answer, GitHub issues with maintainer response.
  • Personal production experience — a bug we hit and fixed in a real SaaS deployment.

We do not publish articles whose primary source is an AI-generated summary, an unverifiable claim, or an unsourced “best practice” that does not survive a cross-check against official docs.

3. Reproducibility rule

No claim ships without a source behind it. For troubleshooting, debugging and how-to articles that means two tiers, and we would rather tell you which tier you are reading than imply they are the same thing:

  • Documented — the baseline for every article. The error string, the command, the flag and the version are checked against the official docs, the library's own source, or the GitHub issue where the behaviour was reported. Anything we cannot trace to one of those is cut before publication, not softened.
  • Reproduced — a smaller set, growing deliberately. The fix was run end to end on a live environment and the run itself is published inline with the article through our VerifiedTestBlock component: the failing command, the real output, the patch, the passing output. When you see that block, you are looking at a transcript, not a summary.

The two-tier rule exists because a 2026 review found that roughly 10% of our early auto-generated drafts contained fabricated details — commands that did not exist, version numbers that did not match, "fixes" that never ran. Tier one closed that hole. Tier two is the stronger guarantee, and it is expensive: every reproduced article means standing up the broken environment for real. We are rolling it out across the highest-traffic troubleshooting pages rather than claiming coverage we do not have.

4. Fact-checking

Before an article publishes, we verify:

  • All quoted error messages exist exactly as printed (verified by running the code).
  • All version numbers match the package or library current at the time of writing.
  • All external links return a 200 status (no 404s, no redirects to unrelated pages).
  • All code samples compile or lint without errors in the documented version.
  • All numeric claims (timings, ratios, counts) trace back to a measurement or a source.

5. Independence from sponsors

We do not write sponsored content. The site participates in affiliate programmes (Vercel, Supabase) and displays advertising through third-party networks (Google AdSense, Adsterra) — see the Affiliate Disclosure. These relationships do not influence topic selection, ranking, or wording of recommendations.

6. Corrections and updates

When something we published turns out to be wrong — whether we catch it or a reader does — we fix it. Significant corrections are recorded inline (a "Correction" block near the affected claim) and surfaced through the article's modifiedDate in the frontmatter. The original post URL never changes (no silent 301s); the corrections stay attached to the same page.

To report an error, email mahdibrbr84@gmail.com with subject "Correction". Please include the URL of the article and a citation for the correct information.

7. Refresh cadence

Articles include a modifiedDate in their frontmatter. We refresh content when:

  • The underlying library releases a major or breaking version.
  • Search Console shows a page has dropped out of the expected position range for its target query.
  • A reader reports a verifiable inaccuracy.
  • The deployment platform (Vercel, Cloudflare) changes a behaviour that affects the article.

8. AI-assisted writing (disclosed)

Some drafts are produced with the assistance of large language models. Every AI-assisted draft is reviewed by a human editor (the author) before publication and must clear the reproducibility and fact-checking rules in §3 and §4. AI assistance is a typing aid, not an authority on correctness.

9. Contact

Questions about this Editorial Policy? Email mahdibrbr84@gmail.com. We aim to respond within 14 business days.