I rank 5th for a port camera I never tried to rank for

Week one: getting 3,164 pages known

The deploy that added the island pages and the port-pair pages took the sitemap from 316 URLs to 3,164. Search Console read it and reported Success, with 3,164 discovered (its own count, on 5 September; the sitemap itself lists 1,960 <loc> entries today, each carrying four hreflang alternates). Discovered is not indexed, and that is the whole of the first week's work.

The thing that surprised me: the Search Console API can report a page's index status, but it cannot request indexing. The URL Inspection endpoint is read-only for that purpose - asking Google to crawl a specific URL is a manual click in the UI, and the quota is roughly 7 to 8 requests a day, shared across the whole property. 3,164 pages at 7 a day is over a year, so pushing pages in one by one is not a strategy. The sitemap does the bulk on Google's own schedule; the daily quota is a scalpel, spent in priority order:

On the first day the quota was already spent before I got to it and every request came back "you've exceeded your daily quota, please try submitting this again tomorrow", which is its own useful lesson: the budget is per day and per property, not per session.

The half of search that does not make you wait

The seven-a-day ceiling is Google's, and only Google's. Bing, Yandex and Seznam accept IndexNow: one POST, up to 10,000 URLs, no daily quota, and ownership proved by serving a key file at /<key>.txt. There is no equivalent from Google - they have said publicly they are evaluating it and that is where it has stayed.

So ops/gsc/indexnow.py reads the same live sitemap and submits the lot in a single call. It refuses to submit an empty sitemap, and refuses if the sitemap holds a URL on another host, because a bulk submit is exactly the kind of thing that should fail loudly rather than quietly ping a stranger's domain. First run: 1,960 URLs, HTTP 200, and Bing Webmaster Tools confirms them arriving. The sitemap itself had never been registered there - Google had it from day one, Bing did not, and nothing tells you. The key file is not written on preview builds - a preview branch must not be able to submit URLs for the live domain.

This matters more than it used to, and not because of Bing's search share. Bing's index is what several AI assistants read when they answer a question about a place, so being in it quickly is part of being quotable at all - the same reason the site publishes llms.txt, an OpenAPI spec and a JSON endpoint per route and per port, and lets every AI crawler in on purpose in robots.txt.

The job that counts it every morning

Submitting is manual. Knowing where you stand should not be, and this is the part that actually keeps the work honest. ops/gsc/indexed.py runs from launchd every morning at 09:40:

Which turns a vague feeling into a line you can watch move:

110 of 180 island pages indexed, and the states are specific enough to act on: Discovered - currently not indexed means Google knows and has not bothered, URL is unknown to Google means the sitemap has not carried it yet, and Crawled - currently not indexed means it looked and declined. Two English pages are still out: /en/island/pag/ is unknown to Google, and /en/island/silba/ was crawled and passed over.

The pair pages - 586 of them - are deliberately not in this tally. They ride the sitemap. They go on the list only if they are still unknown once the islands are in, which is the ponytail rule written into the top of the script: do not measure what you are not going to act on.

The honest baseline

There is no way to dress that up and I am not going to try. It is a site that has been live for less than a week, in a market with entrenched incumbents, and Google is showing it to almost nobody. GA4 has nothing at all for the period - the consent gate was blocking it until 5 September, which is its own lesson and not this post's.

What a month of near-zero traffic is good for is direction. 172 impressions is too small to prove anything about volume, and just big enough to show which kind of page a search engine is willing to put in front of a person.

What I expected to rank

The head terms. The phrases you would put on a whiteboard if someone asked what a Croatian ferry site should rank for:

Split - Supetar is the busiest car ferry crossing in Croatia and the site is on page six for it. That is not a defect in the page, and this is where the analytics run first sent me wrong.

The recommendation I retracted the same day

The run's advice was: Split - Supetar sits at 57, over-invest in that page. So I opened it. The German title already reads Fähre Split – Supetar (Brač) · Fahrplan 631 - a near-exact match for the query, with the crossing duration and the reservation rules already inside the result snippet. There is nothing to fix on the page.

Then I checked where "position 57" came from. One impression. A single time, someone in Germany was shown this site somewhere down page six, and that one sample became an average position, and the average position became a finding. Position from n=1 is noise. It was presented to me as a number and I nearly spent a day on it.

A second recommendation went the same way: "http:// is indexed, we have a canonical split." I had read dist/_redirects, seen only / /en/ 302, and concluded the scheme redirect was missing. One curl -I showed Cloudflare returning a 301 before _redirects is ever consulted. The redirect file was not the only redirect layer, and the file was the only thing I looked at.

Two of nine recommendations retracted the same day they were written, both for the same reason: the data was read without opening the artifact it describes. And chasing the first bad one is what found the real bug, further down.

What actually ranks

Sorted by position rather than by what I hoped for, a different site appears:

And the pages behind them: de/ferry/sumartin-brac-makarska at 6.3, de/ferry/zadar-gazenica-preko-ugljan at 9, de/port/lopar at 11. Every single one is a page about one specific thing with its full name on it. Nothing generic appears anywhere near the top.

This is not a clever insight, it is how a new site with no authority ranks at all. But it is very different reading it as a general principle and reading it as a list of the exact eight phrases your own site is currently winning.

The cameras: the one thing nobody else has

Three of the eight are camera queries. Somebody in Croatia types hak kamera porozina into Google because they are about to drive to the port and they want to see how long the line is. HAK - the Croatian automobile club, which runs the national road camera network - publishes those feeds. I embed the relevant one on the page of every port that has one, next to the timetable, so the answer to "should I leave now" is on a single page.

Three things about this that I did not appreciate until the Search Console data:

And then the titles

Going to fix that is what surfaced the larger bug. Here is what a port page was telling Google it was:

Trajekti i katamarani iz luke Zadar Liburnska obala · plovidbeni red · Croatian Ferries
                                                                       87 characters

Google shows about 60. Route pages have had a guard for this for a while - past 60 characters the · Croatian Ferries suffix is dropped so the route name survives. Port pages never got the same guard. Nobody decided that; the port templates were written later and the guard simply was not carried across.

The fix is a shorter stem plus the same guard the routes already had: Trajekti iz luke {port}, Fähren ab {port}. 278 over-length titles down to 6, and those 6 are the longest Croatian port names, which can stay. 146 site tests pass on it.

The uncomfortable part is how long this sat there. The site's whole reason to exist is reading badly formatted schedules so a person does not have to, and in the one line a person actually reads before deciding to click, the text was cut mid-word on most of the site.

Saying it in the title, without lying

With room in the titles, the camera could go in them:

de/merag     Fähren ab Merag (Cres) · Fahrplan und Live-Kamera
en/supetar   Supetar (Brač) ferry timetable and live camera
en/bol       Bol (Brač) ferry timetable · Croatian Ferries      <- no camera, no claim

16 of the 99 ports have a camera. The tempting version is to put "live camera" on all 99 and let the click-through sort it out. That is how you teach a search engine, and a person, that your titles are not to be trusted - and the whole value of this site over an operator PDF is that it does not waste your time. So the 16 are resolved against the camera map at build time rather than asserted, and the other 83 promise nothing they do not have.

Postscript: two of the best-ranking pages were 404s

After this was written I ran Cloudflare's agent-readiness scan on the domain, and its demand signals panel - paths AI assistants ask for and do not get - was the most useful thing in the whole exercise. The dead paths were route URLs without their disambiguating suffix. When a second operator or a second line with the same endpoints appeared, the slug gained a suffix (split-supetar-brac became split-supetar-brac-631 and split-supetar-brac-krilo) and the original URL was left to die.

Search Console was still serving those old URLs. de/ferry/zadar-gazenica-preko-ugljan/, position 9. de/ferry/zadar-gazenica-brbinj-dugi-otok/, position 11. Both 404. Two of the best-ranking pages on the site, in the table I had just finished celebrating three paragraphs earlier, were dead links - and the ranking table cannot tell you that, because it reports the URL Google shows, not the status code it gets. Every superseded slug now 301s to a real page in all four languages, 124 rules generated from the route list.

The other number from that scan puts the whole post in proportion. In 24 hours: 596 AI answer retrievals - ChatGPT-User 363, Applebot 213, PerplexityBot 20 - against 1 Google click in a month. The audience that has actually found this site is not human yet.

What is still open

What I would do differently

The analytics skill that produced this run now keeps a ledger: every recommendation is written down with the one metric it will be judged on, so the next run scores this one instead of generating fresh advice forever. Two of the nine are already marked retracted, with the reasoning, which is the part I would have quietly forgotten. SEO changes take three to four weeks to register, so there is nothing to report yet, and an unmoved number next week means too early, not failed.