admin
5bea5f2ebf
COPY.md section 7: five Hungarian posts for Tue/Thu 19:00 over three weeks, each with a source comment per claim and one link. The Monday post (2026-10-12, 6.2) is untouched and no slot shares its day. fb_probe.py gains --link (default unchanged). Every scheduled post used to attach the home page's preview card whatever its text said, so a post about /teszteles would have sent the people who clicked its card to the home page. build_parser() split out of main() so a test can parse argv. Red-proved: both new tests fail with "Namespace object has no attribute link" without the flag. Search Console audit (seo-2026-10-10/not-indexed.md): all seven not-indexed URLs with a verdict each - four expected by design, two waiting on Google's crawl queue, one fault on our side. That one is /api/contact, the contact form's POST endpoint crawled as a page; robots.txt now disallows /api/. The performance baseline (0 clicks, 47 impressions, position 73, nine queries) is recorded there to compare against in a month.
7.1 KiB
Search Console — the seven not-indexed URLs, with a verdict each (2026-10-10)
Read in the operator's own Chrome (Claude in Chrome, property
sc-domain:felhom.eu), by opening each of the five „not indexed" reasons and copying its URL list. Property language is Hungarian, so the reason names are quoted as Search Console shows them.State at the time of reading: 6 indexed, 7 not indexed, five reasons. Last index update 2026-10-04.
The table
| # | URL | Search Console's reason | Verdict | Why |
|---|---|---|---|---|
| 1 | https://www.felhom.eu/ |
Alternatív oldal megfelelő kanonikus címkével | EXPECTED | The www. host serves the same page and its canonical points at https://felhom.eu/. Exactly one of the pair should be indexed, and the right one is. Nothing to fix. |
| 2 | https://www.felhom.eu/kapcsolat |
Alternatív oldal megfelelő kanonikus címkével | EXPECTED | Same as #1, for the contact page. |
| 3 | https://www.felhom.eu/api/contact |
Nem található (404) | OUR SIDE — FIXED | This is the contact form's POST endpoint, not a page; a GET returns 404. Google reached it anyway (first crawled 2026-04-29) and reports a 404 on the site. Fixed by adding Disallow: /api/ to website/robots.txt in this session, so it is not crawled as a page again. The endpoint itself is unchanged and the form still works. |
| 4 | http://felhom.eu/ |
Átirányítást tartalmazó oldal | EXPECTED | The plain-HTTP home page redirects to HTTPS. The redirect is the point; the HTTPS page is indexed. Nothing to fix. |
| 5 | https://felhom.eu/letoltes |
Felfedezve – jelenleg nincs indexelve | NOT A FAULT — Google's queue | Google knows the URL and has not crawled it yet („Utolsó feltérképezés: nincs"). The page is reachable, is in the sitemap, is linked from the nav and carries its own title, description and canonical. This is the crawl budget of a new, low-authority site, not a defect. The lever is the operator's „Indexelés kérése". |
| 6 | https://felhom.eu/en/download |
Felfedezve – jelenleg nincs indexelve | NOT A FAULT — Google's queue | Same as #5, for the English twin. |
| 7 | https://felhom.eu/sitemap.xml |
Feltérképezve – jelenleg nincs indexelve | EXPECTED | A sitemap is not a page and is never meant to appear in results. Google crawled it (2026-09-17) and correctly did not index it. Nothing to fix. |
Totals: 4 expected by design, 2 waiting on Google, 1 fault on our side, fixed in this session.
What was fixed here
website/robots.txt gained, with its reason in a comment:
Disallow: /api/
Nothing else on the site was changed for indexing. The canonical tags, the hreflang pairs, the
per-page titles and the sitemap were already correct and were deliberately not redone.
The sitemap entry is stale — this needs the operator
Read on the same day from Search Console → Indexelés → Webhelytérképek:
| Submitted sitemap | Type | Submitted | Last read | State | Pages discovered |
|---|---|---|---|---|---|
https://felhom.eu/sitemap.xml?v=2 |
Webhelytérkép | 2026-02-11 | 2026-10-05 | Sikeres | 8 |
Two things are wrong with that row, and neither can be fixed from the website:
- The submitted URL carries
?v=2.robots.txtadvertises the cleanhttps://felhom.eu/sitemap.xml, so the submitted entry and the advertised one are different URLs. - It reports 8 discovered pages while the sitemap holds 18. The file listed 16 after the English
twins landed on 2026-10-08 and 18 after this session added
/tesztelesand/en/testing. The number 8 is what Google took from an older read; the last read (2026-10-05) predates both changes.
The exact clicks for the operator
All of this is in Search Console, property felhom.eu. CC does not submit anything here; these are the operator's own clicks.
A. Remove the old sitemap entry
- Left menu → Indexelés → Webhelytérképek.
- In „Beküldött webhelytérképek", click the row
https://felhom.eu/sitemap.xml?v=2. - Top right of the detail panel → the three-dot menu → „Webhelytérkép eltávolítása".
B. Submit the clean sitemap
- Same page, the „Új webhelytérkép hozzáadása" box at the top.
- Type
sitemap.xml(thehttps://felhom.eu/part is already in front of the field). - Click KÜLDÉS. The row should come back as „Sikeres" within a few minutes, and the discovered page count should rise from 8 towards 18 over the following days.
C. Ask for indexing on three pages For each of these three URLs in turn:
https://felhom.eu/https://felhom.eu/teszteleshttps://felhom.eu/alkalmazasok
- Paste the URL into the search box at the very top („A(z) »felhom.eu« alá tartozó bármelyik URL-t ellenőrizheti") and press Enter.
- Wait for the check to finish (a few seconds).
- Click „Indexelés kérése", then wait for the „Indexelés kérve" confirmation before moving to the next URL.
Google rate-limits this, so if the third one refuses, leave it for the next day. Requesting indexing is a hint, not a command — it usually takes days, and it does not guarantee indexing.
Performance baseline — the number to compare against in a month
Search Console → Teljesítmény, search type Web, last 3 months (2026-07-07 … 2026-10-06):
| Metric | Value |
|---|---|
| Összes kattintás | 0 |
| Összes megjelenítés | 47 |
| Átlagos CTR | 0 % |
| Átlagos pozíció | 73 |
Every query with an impression (there are only nine, so this is the whole list, not a top-10 cut):
| # | Query | Clicks | Impressions | CTR | Position |
|---|---|---|---|---|---|
| 1 | felhő tárhely | 0 | 18 | 0 % | 98.6 |
| 2 | felhőtárhely | 0 | 5 | 0 % | 99.0 |
| 3 | felhő alapú tárhely | 0 | 3 | 0 % | 92.0 |
| 4 | biztonsági mentés dokumentumok | 0 | 2 | 0 % | 85.0 |
| 5 | ingyenes felhő tárhelyek | 0 | 2 | 0 % | 95.5 |
| 6 | minden ok | 0 | 1 | 0 % | 2.0 |
| 7 | saját meghajtó | 0 | 1 | 0 % | 58.0 |
| 8 | saját felhő tárhely | 0 | 1 | 0 % | 83.0 |
| 9 | felhő szolgáltatás | 0 | 1 | 0 % | 100.0 |
What this says, plainly. Eight of the nine queries sit at position 58–100 — that is page six and worse, where nobody looks, which is why 47 impressions produced zero clicks. They are also the wrong queries: „felhő tárhely" is what someone types when they want Google Drive, and against Drive, iCloud and Dropbox this site will not rank. The one query at position 2 („minden ok") is an accident of wording, not an intent anyone can sell to.
The conclusion this baseline supports: search will not deliver the first five testers. The page built in this session exists so that people who arrive from a person — a colleague, a friend, a Facebook group — land on something that answers „what do I need, and what do I get". Search is the slow lane and is worth keeping correct, not worth waiting for.
Re-read this table in a month (2026-11-10) and compare the four headline numbers and the position of any query that mentions „otthoni szerver" or „saját felhő", which is what the new page targets.