DEV Community: Mirko Stahnke

Moving a Kids' Search Engine to Its Own Brand and Domain: kids.findnix.eu to Suchpanda, Without Breaking a Single Link

Mirko Stahnke — Wed, 21 Oct 2026 19:42:07 +0000

Since July, our search engine for children lived at kids.findnix.eu, a subdomain of the general-purpose search engine findnix.eu. This month we moved it to its own name and its own domain: Suchpanda at suchpanda.de. This post explains why we split the two, and how we did the move without breaking a single old link, sitemap or admin tool.

Why a subdomain was the wrong home

A kids' search engine and an adult-capable general search engine can share a codebase and a database, but they should not share an identity. These were our reasons:

Different promises. findnix.eu has accounts, advertising packages, a points system, a domain marketplace and a user area for site owners. The kids site has none of that: no tracking, no ads, nothing a child has to type into an account form. Parents who see the same brand on both will reasonably wonder where the line between them is.
Different trust boundaries. Every filter, blocklist and reputation signal that applies to the parent can leak onto a subdomain, and the other way round. A children's service should not be one spam report away from being treated like the site it was spun off from.
Different rules for content. The kids index is curated and checked by hand: no war, no violence, no sex education, no dangerous experiments. The general index is open by design. Two sets of rules belong under two names.
A brand of its own. The kids site already had two mascots, Uli and Nele. It now has a third, the Suchpanda ("search panda"), and a name that says what it does ("such" = search) without carrying the parent's brand.
Clean operations. Public pages, robots rules, sitemaps and webmaster accounts are separate per domain. Giving the kids site its own domain means its own robots.txt, its own sitemaps and its own Search Console, Bing and Yandex properties.

The requirements for the move

suchpanda.de is the canonical home; suchpanda.eu and kids.findnix.eu redirect to it.
Every old URL keeps working through a 301, including paths and query strings.
Admin tools that are called across domains must not be redirected. Our admin imports images and videos by calling two scripts on the old host with a shared key. They stay on kids.findnix.eu.
No downtime, no broken sitemaps, no lost links in the database.

Step 1: domains and DNS

We registered both domains and pointed @ and www at the server. The .eu domain came up within minutes. The .de domain did not: the registry (DENIC) kept a placeholder nameserver entry (not.connected.suchpanda.de IN A 127.0.0.1) while the registrar's own nameservers already answered correctly for the zone. A quick look with whois -h whois.denic.de and dig against the nameservers showed that the zone was fine and the nameserver update had simply not reached the registry. The registrar fixed it on their side, and a few minutes later the domain resolved everywhere.

Useful checks that saved us hours of guessing:

# What does the registry say?
whois -h whois.denic.de -- "-T dn suchpanda.de"

# Does each nameserver answer authoritatively with the same zone?
for ns in a.ns.example.net b.ns.example.net; do
  dig +norec SOA suchpanda.de @$ns | grep -c 'flags:.* aa'
done

Step 2: one vhost, three names

The kids site runs in its own PHP-FPM pool with an open_basedir limited to its own directory. Instead of copying the site, we added suchpanda.de and www.suchpanda.de as aliases of the existing web domain. That keeps one document root and one pool, and the Let's Encrypt certificate simply carries all three names:

v-add-web-domain-alias USER kids.findnix.eu suchpanda.de,www.suchpanda.de
v-add-letsencrypt-domain USER kids.findnix.eu suchpanda.de,www.suchpanda.de

suchpanda.eu became a separate, empty web domain with its own certificate and a forced 301 to https://suchpanda.de$request_uri.

Step 3: the redirect that keeps the admin tools alive

All traffic for the old host is redirected, except two admin scripts and the ACME challenge path (otherwise certificate renewals for the old name would loop):

set $sp_redir 0;
if ($host = kids.findnix.eu)    { set $sp_redir 1; }
if ($host = www.suchpanda.de)   { set $sp_redir 1; }
if ($uri ~ "^/(admin-import-a|admin-import-b)\.php$") { set $sp_redir 0; }
if ($uri ~ "^/\.well-known/acme-challenge/") { set $sp_redir 0; }
if ($sp_redir) { return 301 https://suchpanda.de$request_uri; }

It lives in a custom include next to the generated Hestia config, so it survives rebuilds. We tested it with curl before and after: the old host answers 301 for pages and 403 (no key) or 200 (with key) for the two admin scripts.

Step 4: code, data and sitemaps

The base URL of the kids app was one constant, but the old name was also hard-coded in about two dozen places. We wrote a small patch script with a dry run, per-file backups and a PHP lint pass, with rules to skip filesystem paths, because they must not change when only the public name does:

the kids base URL, the sitemap generators and robots.txt;
the constants that build public URLs for books, tasks and study aids in the admin;
71 absolute links stored in the database (REPLACE() on https://kids.findnix.eu/ after a dump);
the footer button on the main site, the RSS feed and the sitemap lines in the main site's robots.txt.

One more detail came from Yandex: in our setup it did not pick up the sub-sitemaps through the sitemap index. So every one of the 129 sub-sitemaps is now listed individually in robots.txt, generated by a small cron job that reads the index every morning and rewrites the file only if it looks plausible and has changed.

What went wrong along the way

While adding the new vhost, Hestia restarted a PHP-FPM version, and the systemd unit refused to start: Failed to set up mount namespacing: Invalid argument (the sandbox option PrivateDevices=true does not work in this container environment). Three sites on that PHP version returned 502 for under a minute until we disabled the sandbox options with a systemd drop-in. We have since applied the same drop-in to every service that uses them, and we now check systemctl show php8.4-fpm -p PrivateDevices before any vhost operation. If you run Hestia in a container, this one is worth knowing.

Checklist if you are planning the same move

Redirect by host, not by path, and keep an explicit exception list for internal tools.
Keep the old host's robots.txt crawlable. If it is blocked, crawlers never see your 301s.
Add the new domain to Search Console, Bing Webmaster Tools and Yandex Webmaster, and submit the sitemaps. Leave the old property in place until you have used the site-move tool.
Reissue the certificate with all aliases once the new name resolves publicly, not before.
Migrate absolute URLs stored in the database, and keep dumps.
Expect consent banners to ask again: cookie consent is per domain.

Result

Suchpanda is live at suchpanda.de. The old URLs redirect, the admin imports still run, sitemaps and robots.txt use the new name, and the kids site finally has an identity that does not depend on its parent. If you want to see it, it is at suchpanda.de.

AI-Written Kids' Content Behind a Human Gate: Picture Books, Story Tasks and Practice Tables in Plain PHP

Mirko Stahnke — Sat, 10 Oct 2026 23:33:43 +0000

When you build learning content for children with an LLM, the model is the easy part. The hard parts are everything around it: who is allowed to see its output, how you catch its mistakes, and what you decide not to teach at all. This is a write-up of three pieces we added to kids.findnix.eu, a curated, ad-free search engine for kids: AI-written picture books, "story tasks" for ages 9 to 14, and practice tables. All of it is plain PHP and MariaDB, no framework, no accounts.

The rule everything else follows

Kids never type into an AI. Nothing is generated while a child is looking at the page. Every text and every picture is produced in advance, reviewed by a person, and only then published. There is no chat box, no "ask the AI", and what a child types into an answer field never leaves their browser.

We documented the reasons in the site's (German) wiki: a model can be confidently wrong, you cannot filter every answer to a free-form question, and a free text box invites children to type their name, school and worries into a third-party API. Pre-generated and approved content avoids all three. The Kinder KI topic cards work the same way.

Piece 1: picture books, with a translation exercise

Each book has a cover and eight pages with two to four short sentences each, for ages 6 to 9, on topics such as courage, friendship, feelings, being new in class and bedtime. They are written in German. Under every page a child can try to translate the text into English and then click "show solution"; the English text exists only as that answer key. A PDF with writing lines and solution pages is generated for printing.

The generation pipeline is deliberately boring:

An LLM returns strict JSON: title, blurb, eight pages, tips, a note for parents, an English translation and a character sheet. Malformed or incomplete JSON is retried up to three times.
A second pass derives the image prompts from the final German text, one per page. When the model wrote the prompts alongside the story, they were sometimes shifted by one page, and they went stale the moment the text was edited.
An image model draws the pages in one of six style presets (flat, watercolor, colored pencil, paper collage, gouache, pastel chalk) so the books do not all look alike.
A human reads every text and checks every picture against its page. Anything wrong gets regenerated.
Only the admin can publish. The PDF is built by a small dependency-free PHP writer (about 180 lines: A5 pages, core Helvetica, embedded JPEGs, text stays selectable).

What the review loop actually caught: pictures showing the whole cast in every scene, a "GYM" sign painted into an illustration despite a "no text" instruction, skin tone and clothing drifting between pages, German idioms that did not belong in a children's book, and a lost toy that was visible in the scenes where it was supposed to be missing. None of that is visible in the JSON.

Piece 2: story tasks that check the model's maths

A story task is a short story and exactly three tasks that get harder from the first to the third, with a field for the child's own solution and a "show solution" button with the answer and the steps. There are seven subjects (maths, physics and IT, chemistry, biology, geography, history, German) and five levels for ages 9 to 14. The maths track climbs from money and time problems to the rule of three, percentages and simple equations.

LLMs get arithmetic wrong, and a wrong answer key is the worst possible failure in a learning product. So every numeric task carries a machine-readable expression next to the prose answer, and the server re-computes it:

// calc is a plain arithmetic expression such as "(12*4)+8"; result is the number the model claims
$v = kids_task_calc($task['calc']);   // small shunting-yard evaluator, no eval()
if (abs($v - $task['result']) > 1e-6 * max(1, abs($v))) $warn[] = 'result mismatch';
if (!kids_task_text_has_number($task['answer'], $v)) $warn[] = 'answer does not state the result';

If the check fails, the draft is discarded and regenerated, up to three times. It still does not replace a human recalculating each task, but it catches most slips before a person ever sees them.

The funniest bug of the whole project: our first batch for geography, chemistry, biology and history came back as maths word problems in costume. A history task asked the child to subtract 1450 from 2026. That is not what "history task" means. Only the maths track calculates now; the other subjects use matching, ordering, explaining and reading maps. Following a spec to the letter and still missing its point is not only a human talent.

Piece 3: practice tables

For each subject there are reference tables with a learn mode (everything visible) and a practice mode (one column hidden, the child types the answer and checks it). Currently 15 are live: all 193 UN member states with capitals and flags (including a "guess the flag" mode), the periodic table with all 118 elements, formula collections for maths and physics, a unit converter, a timeline of key dates, and German grammar tables for parts of speech, cases, articles, tenses and sentence parts, plus a few biology tables.

A table is stored as plain text lines, one per row:

Europe | Germany | Berlin | 1 | de
Geometry | Area of a rectangle | A = a · b ## a*b ## ab | 1

The ## part holds spellings that count as correct but are not shown. The interesting problem is deciding when a typed answer is right. Names are compared leniently (case, umlauts and accents do not matter, every capital of a country with several counts). Formulas need the opposite treatment. Our first version stripped everything except letters and digits before comparing, which made a+b a correct answer for the area of a rectangle. Formula columns now use their own normalizer in which operators and brackets count and only the spelling of multiplication, powers and Greek letters is flexible:

function normF(s) {
  s = String(s).toLowerCase().replace(/\s+/g, '');
  s = s.replace(/²/g, '^2').replace(/π/g, 'pi');
  return s.replace(/[·×*x]/g, '')   // a*b, a x b, a·b and ab are the same
          .replace(/[÷:]/g, '/')
          .replace(/[−–—]/g, '-')
          .replace(/,/g, '.');
}

The periodic table also has a colored overview: a CSS grid of 118 buttons in the classic layout, ten element groups with a legend that dims everything else, and a self-test mode that hides symbols or names until you tap a cell. The flags are SVG files from the MIT-licensed flag-icons project, self-hosted. Emoji flags were the first idea, but Windows shows them as two letters. The PDF writer only takes JPEG and the converters available on the server drew several flags wrongly, so the printable sheets leave flags out rather than ship wrong ones.

One honest limitation: the flags are decorative images, so the "guess the flag" mode is not usable with a screen reader. The normal text mode is.

What we deliberately left out, and why

There are no wars, no war zones, no sex education, and no description of biological or chemical processes that could be abused for weapons, explosives, poisons or drugs. In history the timeline contains inventions, discoveries and turning points; in geography, peaceful destinations and nature. The country table lists states and capitals and says nothing about conflicts.

The reasons are practical rather than ideological. A child reading alone cannot ask anyone when something frightens them, and a three-sentence task cannot treat a war neutrally or with the context it needs. Sex education belongs first with parents and then with school, where timing, vocabulary and the maturity of the individual child can be taken into account. And anything that reads like a recipe for hazardous substances is a legal and safety risk, so chemistry stays with salt, sugar, water and sand, and electricity experiments use batteries only.

Enforcement has three layers. The rules go into every LLM prompt. A word filter scans every text for terms about war, weapons and hazardous substances, and sex education, and a draft with a hit is discarded or flagged. The publish button refuses to publish while the filter has a hit. A human reads everything before it goes live. The filter matches words, not meaning, and it is strict on purpose: an older word list once flagged the German word for noodles because it contains "nude". We would rather rephrase a harmless sentence than let a hit through.

Where it stands

As of October 11, 2026: 33 picture books exist, 13 of them published; 36 story tasks across seven subjects are live; and there are 15 practice tables. The wiki documents the decisions in German: picture books, story tasks (including the section on what is left out) and practice tables.

If there is one lesson to take away: let the model draft, make the server check what can be checked mechanically, and keep a person between the output and the child. Try it at kids.findnix.eu/aufgaben.php; the content is German, because that is who it is for.

A Tour of the findnix.eu User Area: 21 Modules for Site Owners and What They Do Under the Hood

Mirko Stahnke — Mon, 05 Oct 2026 20:30:28 +0000

findnix.eu is a GDPR-first metasearch engine with its own index, and the account area has grown into a toolbox for people who run websites. Most modules are free with an account; the advertising packages are the paid part. This is the full tour, grouped by what you want to get done, with a note on how each one works where that is interesting.

Get your site into the index and keep it healthy

Submit a sitemap. Register a domain and a sitemap URL (XML, a PHP script that outputs XML, or an RSS 2.0 feed) or submit single URLs. Submissions are checked against spam lists and for duplicates. You prove ownership with a small token file on your server or a meta tag in your homepage head, and the crawler picks the sitemap up on its next run. If your sitemap carries <title> and <description> per URL, we use them directly, so the page doesn't need to be fetched just for its metadata.

Sitemap Generator. Enter a start URL, choose a crawl depth of 1 to 4 and up to 200 pages, edit the list it finds (add or remove URLs, set change frequency and priority per page) and download a standards-compliant sitemap.xml. It skips external links, media files and typical admin and login paths.

DNSBL Tester. Checks a domain or IP against 20 DNS blacklists (Spamhaus ZEN, SpamCop, Barracuda, SORBS and others) and sends a certificate with a unique number by e-mail. You can schedule a repeat check every 7, 14, 28 or 31 days, and each certificate page offers an embeddable SVG badge. One implementation detail: the lookups go through a dedicated external DNS resolver, because shared hosting resolvers get rate-limited by some blacklist providers and then report false "listed" results.

Analytics. A visitor counter with no cookies and no IP storage. You register a site, paste one script tag into your head, and get views for today, the last 7 days and in total, the top pages of the last 30 days and the split by device type.

Images

Reverse image search. Upload an image (JPG, PNG, GIF or WebP up to 5 MB) or paste a URL, and the tool searches findnix's own image index plus IQDB for similar images.

Image protection. Adds a text or logo watermark to many images at once, with five positions, adjustable size and opacity, and WebP as the default output format to save space. It is deliberately internal: there is no embed code, the protected images are just offered for download.

Tools for building

Generator suite. Nineteen small tools in one place: RSS feed, meta tags (including Open Graph and Twitter Card), a CSS generator with six sub-generators (button, box shadow, border radius, gradient, text shadow, animation), .htaccess, password, QR code, color palette, Lorem Ipsum, Base64, slug, image placeholder, favicon links, mailto: links, hash (MD5, SHA-1, SHA-256, SHA-512) and a short URL generator with a private list and click counter. Most of them run entirely in the browser, and nothing is sent to the server. The exceptions are the CSS gallery where you can share designs, the short URL generator, and the QR and placeholder tools, which call external APIs. The password generator uses the Web Crypto API, and the color and button generators show the WCAG contrast ratio live.

Form generator. Assemble a form from a palette of field types, label and reorder the fields, choose where it posts to (your own endpoint, Formspree and similar) or fall back to mailto:, and copy or download a complete HTML document. It is 100% client-side: no form, field name or target address is ever stored. Reordering uses arrow buttons instead of drag and drop on purpose, so it works without a mouse, and the generated markup has real labels, aria-required and an aria-live status region.

Widgets for your own site

Rating widget. Collect reviews with stars, an emoji mood, category ratings (service, quality, speed) and a free-text comment, as a floating button or embedded inline. Each registered site gets a dashboard with all ratings and a delete function, and one rating per IP and day is accepted to prevent repeat votes.

Share widget. Share buttons for Facebook, Instagram, X, Pinterest, Threads, TikTok, WhatsApp, LinkedIn and a copy-link button, in three designs and with your own colors, without cookies or stored IP addresses.

Ad widget. Embed a findnix banner (728×90, 300×250 or 300×100) on your own site and earn points for impressions and clicks from different visitors.

Advertising and visibility

Advertising is a flat rate with no bidding and at most three ads per page, always labeled as ads. Booking offers three plans: Starter (currently 9 € per month, one ad, DE/AT/CH targeting), Business (49 €, up to three ads, EU-wide, real-time dashboard) and Enterprise (199 €, up to ten ads, all countries, priority placement). You pay by invoice and bank transfer. My ad is where you write the ad itself (title, display URL, target URL, description, keywords, country codes) with a live preview, and ads are reviewed within about a day. Highlight puts a frame and a star on your main domain when it shows up in results anyway; the organic order does not change, and it requires an approved sitemap. Sell a domain gives a quick heuristic valuation (a 0 to 100 score, a category and a rough price range based on TLD, length, hyphens, digits and industry keywords) and lets you list the domain as an ad. Inquiries arrive in a mailbox inside your account, so your e-mail address never appears publicly.

AI

AI Hub is a bring-your-own-key portal at ai.findnix.eu: chat with Claude, ChatGPT, Gemini and Mistral, image generation with DALL-E and Stability AI, text to speech with ElevenLabs, a code assistant and video generation with Runway. You use your own provider keys and are billed by the provider, not by us. Keys are encrypted with AES-256-GCM, each with its own nonce, and a link in your account signs you in without a second registration.

Community and points

Many actions earn points, and one point is worth 1.5 cents toward plans and highlights. The wishlist takes feature ideas and pays 50 points when one is implemented. Donations let you choose a charity, generate a donation receipt with bank details and a GiroCode QR, and pays 5 points per euro after you upload the transfer receipt and we check it. My journal lets you submit articles and finds for the findnix.eu Journal, which are translated into 24 languages after approval.

Your account

Security & 2FA adds TOTP two-factor authentication (FreeOTP, Google Authenticator or Authy) with single-use backup codes, plus password changes. Profile holds your avatar, display name and billing details, and your personal invite link: every friend who registers through it earns you 30 points.

Why it looks like this

The pattern across all of it is the same: do as much as possible in the browser, store as little as possible on the server, and say so on the page. The modules are plain PHP and MariaDB like the rest of findnix.eu.

The user area is at findnix.eu/user, and every module is described in more detail, in 24 languages, in the module section of the Journal.

Building a 24-Language Journal in Plain PHP: AI Translation, Hash-Based Staleness, and a Points-Gated Community

Mirko Stahnke — Mon, 05 Oct 2026 19:08:18 +0000

findnix.eu is a GDPR-first metasearch engine with its own index. Search was never the whole story, so we added a Journal: articles, a weekly digest, "finds" (sites worth a look), user questions and answers, and a profile page for every domain in the index. It's plain PHP 8.4 and MariaDB, no framework, in the same codebase as everything else. These are the decisions that mattered.

One table, four post types, translations on the side

Articles, digests, finds and questions share one table with an ENUM type column. Translations live in their own table keyed by (post_id, lang), so the original post never changes shape and a missing language is just a missing row. German is the source language; the other 23 EU languages are translations. Each language version gets its own URL (/journal/fr/some-slug) with hreflang links, and the sitemap lists every version with its translated title and description, so the translated pages end up in our own search index too.

Markdown without a library

The renderer is about 100 lines. The one rule that keeps it safe: escape everything first, then generate only the tags we allow.

$t = htmlspecialchars($t, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
// only now turn [text](url) into <a>, and only for http(s), mailto or local paths

Raw HTML in a post simply shows up as text. Links from user content get rel="nofollow ugc".

Translating HTML with an LLM, and not trusting the result

Posts are rendered to HTML once, and that HTML is what we translate: split at <h2>–<h4> boundaries into chunks of a few thousand characters, one gpt-4o-mini call per chunk, with the instruction to keep every tag and attribute and translate only visible text. Title and teaser go in a separate call that returns JSON.

The important part is what happens afterwards. An article is attacker-controlled text as far as the model is concerned: a user post could contain instructions, and the model might obey them and emit markup. So the translated HTML goes through a DOMDocument whitelist (a short list of tags and attributes, URL schemes checked) before it is stored. If the model produces a <script>, it never reaches a page.

"Is this translation stale?" is not an `updated_at` question

First version: compare the translation's timestamp with the post's updated_at. It broke immediately, because updated_at moves when you pin a post, change its status, or bump the view counter. Every pin would have re-translated 23 languages.

Now each translation stores a hash of the source text it was made from:

MD5(CONCAT(title, CHAR(10), COALESCE(excerpt, ''), CHAR(10), body_md))

A translation is current if its stored hash equals the post's current hash. Pinning, status changes and view counts don't matter any more. (View counters are updated with updated_at = updated_at anyway, so they don't touch the timestamp.)

Two triggers, one idempotent worker

Translating all languages for a post takes a minute or more, which is too long for a save request. We use two triggers:

In the editor: after saving a published post, the admin page loops over the missing languages from the browser, one request per language, with a progress bar. Instant feedback, no server timeout.
A cron job every 15 minutes picks up everything the editor didn't: a digest approved from the list view, a user submission approved by a moderator. It takes a file lock so runs never overlap, skips posts edited in the last ten minutes (the editor is probably handling those), stops after five consecutive failures instead of hammering a broken API, and stays silent when there is nothing to do.

Both call the same function and write with an upsert, so running them twice is harmless.

The bug worth sharing: Slovak came back as Slovenian

Our first batch of translations looked fine until we noticed that the Slovak and Slovenian titles were identical, for 8 of 9 posts. The prompt said "Slovenčina (sk)". The model read the name, not the code, and answered in Slovenian.

The fix was to use English language names plus an explicit contrast in the prompt: "Slovak (the language of Slovakia; NOT Slovenian and NOT Czech)", and the mirror image for Slovenian, Czech, Croatian, Danish and Swedish. Re-running the nine posts produced correct Slovak.

How we found it matters more than the fix. Asking the model to identify the language of each translation caught only 2 of the 8 wrong ones. A plain GROUP BY title HAVING COUNT(*) > 1 across languages caught all of them. For batch-generated content, cheap invariants beat asking an LLM to grade itself.

Community features, all on one points ledger

Every user action (a comment, an answer, a question, a submitted article, a domain review) goes through the same two helpers: one that grants points with a daily cap, and one that revokes them. The rules we settled on:

Points are granted only when the content becomes visible, never at submit time.
Spam or deletion revokes exactly what was granted. Each comment remembers its points for that reason.
A user's first comment, anything containing a link, and anything the blacklist flags goes to a moderation queue. Once a user has visible content, they are "trusted" and skip the queue.
Answering your own question earns nothing, and the best-answer bonus can't be given to yourself.

The amounts live in a settings table, so we can tune them in the admin without a deploy.

Domain profiles without scanning 37 million rows

Every domain in the index gets a page with its page count, sitemap count, first-seen date and a few sample pages. Counting rows per domain in a 37-million-row table on every request is a non-starter, so the count is capped inside a subquery and the result is cached:

SELECT COUNT(*) FROM (
  SELECT 1 FROM fnx_sitemap_urls
  WHERE domain = ? AND status = 'aktiv' AND adult = 0
  LIMIT 100000
) t

Large domains show "100,000+", which is honest and costs one index range scan. A batch job refreshes the numbers slowly, with a pause between domains, rather than all at once.

One more false positive

Our spam blacklist matched keywords as substrings. The keyword anal blocked analyst.nl, analytics-agentur.ch and psykoanalyse.no; sex would have blocked sussex.ac.uk. We added a =word syntax that matches only at word boundaries (no letter or digit directly before or after) and left long, unambiguous terms as substrings so that concatenated spam domains still get caught. Of the 27 indexed domains the old filter had hidden, all 27 were false positives.

Takeaways

Store a content hash with derived data instead of comparing timestamps.
Treat LLM output as untrusted markup, even when you wrote the input.
Name the language in the prompt, not just its code, and add a "not X" clause for close neighbours.
Cheap data invariants find batch bugs that "ask the model" checks miss.
Put every reward or privilege behind one ledger with caps and a way to take it back.

The Journal is live at findnix.eu/journal, and the questions section is at findnix.eu/journal/fragen.

Bring Your Own Key: Building an AI Portal That Never Touches the Billing

Mirko Stahnke — Sun, 23 Aug 2026 18:47:18 +0000

Bring-your-own-key, not another subscription

Every few months another "all AI models in one place" product shows up, and almost all of them work the same way: you pay them a subscription, and they resell access to Claude, GPT-4, Gemini and friends at a markup. That's a reasonable business, but it's not the only way to build this, and it's not the way ai.findnix.eu works.

AI Hub is a bring-your-own-key portal: you paste in your own Anthropic, OpenAI, Google, Mistral, Stability AI, ElevenLabs and Runway keys, and the portal just gives you one consistent interface — chat, image generation, text-to-speech, a code assistant, video generation — over whichever of those you've connected. Billing happens directly between you and the provider. The portal itself charges nothing for API usage, because it never touches the money side at all.

Keys are the one thing that has to be paranoid

The whole trust model of a BYOK product rests on one thing: can users believe their API keys — which are effectively bearer tokens for their own paid accounts — are safe. Every key is encrypted with AES-256-GCM before it touches the database, with a unique nonce per key (so two identical keys never produce identical ciphertext, which matters for preventing pattern analysis against the stored blobs). The master key lives in a config file that's explicitly blocked from direct HTTP access at the nginx level, as a second layer independent of PHP actually executing the file correctly.

function encryptApiKey(string $plaintext): array {
    $key   = hex2bin(MASTER_KEY);
    $nonce = random_bytes(12);
    $tag   = '';
    $cipher = openssl_encrypt($plaintext, 'aes-256-gcm', $key, OPENSSL_RAW_DATA, $nonce, $tag, '', 16);
    return ['enc' => base64_encode($cipher . $tag), 'nonce' => base64_encode($nonce)];
}

Nothing exotic — GCM gives you authenticated encryption for free, so a tampered ciphertext fails to decrypt rather than silently returning garbage.

Two identities, one login, no forced choice

AI Hub is a sibling project to findnix.eu, a GDPR-focused EU search engine, and that created an actual product question: should AI Hub have its own user accounts, or piggyback on findnix.eu's existing ones?

The answer ended up being both, deliberately. At signup you choose: a standalone AI Hub account, or one linked to your findnix.eu account with a shared login. Existing findnix.eu users don't have to fill out a second registration form at all — a link in their findnix.eu account silently provisions a linked AI Hub identity and drops them straight into the dashboard, authenticated.

That "silently provisions" step runs over a short-lived, single-use signed token rather than any shared session or cookie trickery between the two domains:

function consumeSsoToken(string $token): ?int {
    $row = /* look up token, reject if used or older than 60s */;
    mark token used;
    $aiUserId = /* look up existing linked account for this findnix user */;
    if ($aiUserId) return $aiUserId;
    // first time: silently create a linked AI Hub account, no form involved
    return createLinkedAccount($row['fnx_user_id']);
}

For linked accounts, password checks go straight to findnix.eu's own password hash rather than a duplicated one — one password, one source of truth, even though the two products keep separate account tables.

Least privilege, even between your own apps

Because AI Hub and findnix.eu now share a physical database (AI Hub's tables live in the same schema with their own prefix, rather than a separate database), it would have been easy to just reuse findnix.eu's own full-access database credentials for AI Hub too. Instead AI Hub gets its own MySQL user, scoped to SELECT, INSERT on the shared users table (enough to look up and create linked accounts) and full access only to its own tables. It's internal plumbing nobody using the product will ever see, but it means a bug in a comparatively young, less-battle-tested part of the stack can't reach past its own tables into the main product's data.

What's next

The provider list — Claude, GPT-4o, Gemini, Mistral, DALL-E, Stability AI, ElevenLabs, Runway — covers the obvious ground, but "bring your own key" as a model scales naturally to whatever shows up next; adding a provider is a new small API wrapper file and an entry in a provider list, not a pricing renegotiation.

If the BYOK model is something you'd rather use than another flat-rate AI subscription: ai.findnix.eu.

Building a Community Wiki Around a Privacy-First Search Engine

Mirko Stahnke — Sat, 22 Aug 2026 23:05:42 +0000

The problem: a search engine needs more than a search box

findnix.eu is a EU-based, privacy-first search engine — "Find alles, speichere nix" (find everything, store nothing) is the tagline. Once real users started using it, the support questions started too: how does the spam filter work, why isn't my site indexed yet, what data do you actually store, how do I report a fake shop I found in the results?

Answering the same questions over email doesn't scale, and a single flat FAQ page doesn't either once you also want space for longer-form, kid-safe explainer articles and general knowledge entries contributed by the community. So instead of bolting a FAQ page onto the main site, we split it out into its own project: wiki.findnix.eu.

Three categories, one wiki

The wiki is organized into three top-level groups, each with its own short-link in the header:

FAQ findnix — how the search engine, the spam filter, the DNSBL cross-check, and the points/rewards system work
Kids findnix — safe, curated explainer content that doubles as background material for kids.findnix.eu
Wiki findnix — general knowledge entries submitted by the community, reviewed before they go live

Every entry goes through a submit.php form and lands in a moderation queue with status='approved' as the gate — nothing is public until someone actually looks at it. That single status column is doing a lot of quiet work: it's the difference between "anyone can publish anything" and "anyone can propose something."

Translation without an embedded widget

The wiki needs to serve an EU-wide audience, and hard-coding 20+ language files for community-submitted content isn't realistic for a small team. The pragmatic fix: a language dropdown that builds a one-time link to Google's translate.goog proxy for the current page, entirely client-side, on click:

function wikiGoTranslate(lang) {
  if (!lang) return;
  var host = location.hostname.replace(/\./g, '-');
  var path = location.pathname + location.search;
  var target = 'https://' + host + '.translate.goog' + path
    + (location.search ? '&' : '?')
    + '_x_tr_sl=de&_x_tr_tl=' + lang + '&_x_tr_hl=de';
  location.href = target;
}

No translation script is embedded or running in the background on the page itself — it's a single click handler that computes a URL and navigates. That turned out to matter more than expected: an earlier version embedded Google's live translation widget directly on the page, and it collided with the sticky header (the widget would inject its own top bar and push the layout around). Moving to a proxy-link model instead of an embedded widget removed an entire class of layout bugs, and it means one less third-party script running continuously against visitors' browsers.

Old links still have to work

Categories used to be addressed by numeric ID (?cat=12). Once the wiki grew nice slug-based URLs (?cat_slug=faq-findnix), old bookmarks and inbound links with the numeric form still needed to resolve — so the numeric path does a lookup and issues a real 301 redirect to the slug URL rather than silently rendering the same content on two different URLs:

if ($catId && !$catSlug) {
    $lookup = db()->prepare('SELECT slug FROM categories WHERE id=?');
    $lookup->bindValue(1, $catId, SQLITE3_INTEGER);
    $row = $lookup->execute()->fetchArray(SQLITE3_ASSOC);
    if ($row && $row['slug']) {
        header('Location: /k/' . $row['slug'], true, 301);
        exit;
    }
}

Small detail, but it's the difference between a wiki that quietly accumulates duplicate/dead URLs over years and one that doesn't.

What's next

The wiki is deliberately simple: SQLite-backed, PHP, no JS framework, no build step. That's a feature, not a limitation — it means the barrier to contributing an entry, or to reading the code and understanding exactly what happens to a submission, stays low. As findnix.eu grows, the plan is to keep leaning on the community to write the FAQ and knowledge entries rather than trying to centrally author everything — the people hitting an edge case are usually the best people to explain it to the next person who hits it.

If you want to see it in action (or contribute an entry), it's live at wiki.findnix.eu.

Building a Search Engine for Kids That Doesn't Track Them

Mirko Stahnke — Sat, 22 Aug 2026 23:05:15 +0000

Search engines for kids usually mean one of two things

Either a heavily filtered wrapper around a big commercial index (which still leaks through things a filter didn't anticipate), or a walled garden with a handful of hand-picked links that goes stale in a month. kids.findnix.eu is an attempt at a third option: build and maintain our own curated index, specifically for kids and teenagers, as a companion project to the main findnix.eu search engine.

The homepage states the promise plainly: "no data is stored, and we only try to present vetted, educationally valuable content." Two mascots, Uli and Nele, sit on either side of the search box — which sounds like a small detail, but user testing with actual kids made clear that a friendly, recognizable interface matters as much as the filtering underneath it.

Curation is a crawling problem, not a filtering problem

Rather than filtering an existing general-purpose index after the fact, kids.findnix.eu runs its own dedicated crawlers:

kids_page_image_crawler.php / kids_page_video_crawler.php — pull images and videos specifically from sources already cleared for the kids index
crawl_sitemap_articles.php, crawl_topic_pages.php, crawl_wissenskarten.php — walk sitemaps and topic pages of vetted educational sites
crawl_wp_generic.php — a generic crawler for WordPress-based educational sites, since a huge share of school/educational content in German-speaking countries runs on WordPress
classify_sonstiges_llm.php — an LLM-assisted classification pass for the long tail of content that doesn't fit a hand-written rule

The result, shown live on the homepage, is a running count rather than a marketing number: pages indexed, images, videos, links. It updates because the crawlers keep running, not because someone typed a number into a template once.

The search box is only half the product

What's easy to miss from the name is that kids.findnix.eu isn't just a search box with a filter — half the site is interactive, kid-facing tools built around learning:

Flag Quiz (flaggenquiz.php) — geography, gamified
Secret Code Workshop (geheimcode_werkstatt.php) — classic ciphers, taught by building them
Riddle Challenge (knobel_challenge.php) — logic puzzles
Train your own AI (ki_trainer.php) — a hands-on, simplified intro to how machine learning classification actually works, aimed at demystifying "AI" rather than treating it as magic
Code Adventure (code_abenteuer.php) — a first, gentle introduction to programming

None of these need the search index at all — they're standalone reasons to visit the site directly rather than only arriving via a search query, which matters for a product whose whole pitch is "safe corner of the internet for kids," not just "safe search results."

Accessibility gets its own crawler, too

a11y_crawler.php checks the site's own HTML structure for accessibility issues — worth calling out specifically because it's easy for a "kids" product to over-index on colorful UI and under-index on actually being usable by kids with different needs. Running the accessibility check as its own recurring job, rather than a one-time manual pass, keeps it from silently rotting as pages get added.

No data stored means no data stored

The "no data stored" line on the homepage isn't just copy — visit counting, for example, is deliberately coarse: one cookie-gated counter per visit session (30 minutes), not a log line per page view, and no data ends up tied to an individual beyond a hashed IP used only to avoid double-counting the same visit:

if (!isset($_COOKIE['kids_visited'])) {
    kids_db()->prepare(
        "INSERT INTO fnx_kids_stats (type, referrer, url, ip_hash, lang, user_agent)
         VALUES ('visit', ?, ?, ?, ?, ?)"
    )->execute([...]);
    setcookie('kids_visited', '1', time() + 1800, '/', '', false, true);
}

That's the whole point of building a dedicated kids product instead of just adding a "kids mode" toggle to the main search engine: every default — logging, cookies, what gets shown, what gets stored — gets re-examined for a young audience specifically, instead of inherited from an adult product and only trimmed down after the fact.

kids.findnix.eu is live at kids.findnix.eu, EU-hosted, and — like the rest of the findnix.eu family — built to be small enough that you can actually read the whole thing and know what it does.

findnix.eu: A GDPR-Compliant Search Engine Built From Scratch

Mirko Stahnke — Wed, 19 Aug 2026 23:23:57 +0000

Introduction

Every major search engine today runs on the same trade: you get results, they get your data. findnix.eu is an attempt to break that trade — a search engine built in the EU, for the EU, that doesn't track you, doesn't build a profile of you, and doesn't sell what it doesn't collect in the first place.

This isn't a pitch deck. It's a working search engine, built and run by one person, and this post is a quick tour of what it actually does.

What you can search

findnix.eu isn't just web search. Over time it's grown into a set of focused search verticals, each with its own index:

Web — general search, combining multiple sources with a preference for sites that submit their own sitemap (a small way to give independent sites a fairer shot than they'd get elsewhere)
News — pulled directly from public-broadcaster media libraries across the EU (ARD, ZDF, Arte, ORF, SRF and more), with a built-in video player — no detour through the broadcaster's own site
Podcasts — full show and episode search via the Podcast Index API, with direct in-browser playback
Images & Videos — licensed, freely usable media
Science — open-access papers via OpenAIRE and BASE
Firmen (Companies) — a growing local business index
Kultur — European cultural heritage via Europeana

There's also a companion site, kids.findnix.eu, built specifically for child-safe search — same philosophy, different audience.

No tracking, stated plainly

No tracking cookies, no IP logging, no cross-session profiling. Search history lives in your browser's local storage only, never on the server. Ads (yes, there are ads — servers cost money) are flat-rate and clearly labeled, not auction-based, and capped at 3 per page.

What's newest

The latest addition is a small marketplace feature: a domain valuation and sale tool. You get a free (unbinding, heuristic) valuation of a domain based on TLD, length, and structure, and can list it for sale for a small amount of points — findnix's internal currency, earned through site activity. Inquiries land in an in-app inbox rather than exposing your email address publicly.

Why build this

Mostly because the alternative — accepting that "free" search always means being the product — never sat right. findnix.eu won't out-scale Google. It doesn't try to. It's trying to be a genuinely different deal: you search, we don't remember, and the site stays funded through ads you can actually see and understand, not ones built on a profile of you.

If that sounds like your kind of search engine, give it a try: findnix.eu

DEV Community: Mirko Stahnke

Moving a Kids' Search Engine to Its Own Brand and Domain: kids.findnix.eu to Suchpanda, Without Breaking a Single Link

Why a subdomain was the wrong home

The requirements for the move

Step 1: domains and DNS

Step 2: one vhost, three names

Step 3: the redirect that keeps the admin tools alive

Step 4: code, data and sitemaps

What went wrong along the way

Checklist if you are planning the same move

Result

AI-Written Kids' Content Behind a Human Gate: Picture Books, Story Tasks and Practice Tables in Plain PHP

The rule everything else follows

Piece 1: picture books, with a translation exercise

Piece 2: story tasks that check the model's maths

Piece 3: practice tables

What we deliberately left out, and why

Where it stands

A Tour of the findnix.eu User Area: 21 Modules for Site Owners and What They Do Under the Hood

Get your site into the index and keep it healthy

Images

Tools for building

Widgets for your own site

Advertising and visibility

AI

Community and points

Your account

Why it looks like this

Building a 24-Language Journal in Plain PHP: AI Translation, Hash-Based Staleness, and a Points-Gated Community

One table, four post types, translations on the side

Markdown without a library

Translating HTML with an LLM, and not trusting the result

"Is this translation stale?" is not an updated_at question

Two triggers, one idempotent worker

The bug worth sharing: Slovak came back as Slovenian

Community features, all on one points ledger

Domain profiles without scanning 37 million rows

One more false positive

Takeaways

Bring Your Own Key: Building an AI Portal That Never Touches the Billing

Bring-your-own-key, not another subscription

Keys are the one thing that has to be paranoid

Two identities, one login, no forced choice

Least privilege, even between your own apps

What's next

Building a Community Wiki Around a Privacy-First Search Engine

The problem: a search engine needs more than a search box

Three categories, one wiki

Translation without an embedded widget

Old links still have to work

What's next

Building a Search Engine for Kids That Doesn't Track Them

Search engines for kids usually mean one of two things

Curation is a crawling problem, not a filtering problem

The search box is only half the product

Accessibility gets its own crawler, too

No data stored means no data stored

findnix.eu: A GDPR-Compliant Search Engine Built From Scratch

Introduction

What you can search

No tracking, stated plainly

What's newest

Why build this

"Is this translation stale?" is not an `updated_at` question