diff --git a/pagerite/app.py b/pagerite/app.py
index 29c76f4..5cca3fa 100644
--- a/pagerite/app.py
+++ b/pagerite/app.py
@@ -30,16 +30,15 @@ walking the tree (``resolve``), moves are slot detach/attach
 
 import asyncio
 import logging
-from collections.abc import AsyncIterator
 from contextlib import asynccontextmanager
 
 from fastapi import FastAPI, Request
 from fastapi.responses import Response
 
-from pagerite import api, files, pages, tracking, translate
+from pagerite import api, files, pages, tracking
 from pagerite.__main__ import DEVMODE
 from pagerite.files import file_store
-from pagerite.state import HOSTNAME, analytics_store, data, frontend, kanta
+from pagerite.state import analytics_store, frontend, kanta
 from collections.abc import AsyncGenerator
 logger = logging.getLogger(__name__)
 
@@ -48,7 +47,6 @@ logger = logging.getLogger(__name__)
 async def lifespan(_app: FastAPI) -> AsyncGenerator:
     """Open the database (migrations run inside kanta.open), load assets, load GeoIP."""
     async with kanta:
-        translate.log_service_urls(data.translate_keys, HOSTNAME)
         await asyncio.to_thread(file_store.load)
         await frontend.load()
         # Decompress/open the DB-IP MMDB once at startup.  Lookups are then
diff --git a/pagerite/translate.py b/pagerite/translate.py
index 086ec04..9098ca3 100644
--- a/pagerite/translate.py
+++ b/pagerite/translate.py
@@ -7,8 +7,7 @@ as base64 — no manual encoding anywhere). This module holds everything
 else: the message structs, the connected-client dispatcher (``Dispatcher``
 — one job at a time per connection, wanted ∩ capable language matching,
 requeue on disconnect), which fragments are pending for a language
-(``pending_items``), storing a result (``store_results``) and the startup
-URL listing (``log_service_urls``).
+(``pending_items``) and storing a result (``store_results``).
 
 Fragments cross the wire as **prose segments**: the model only ever
 receives plain text runs (Job.texts) plus per-segment context surrounds
@@ -19,14 +18,12 @@ markup never leaves the server — reassembly is offset splicing
 
 import asyncio
 import logging
-import os
 
 import msgspec
 from fastapi import WebSocket, WebSocketDisconnect
 from kanta import Kanta
 
 from pagerite import i18n
-from pagerite.__main__ import DEFAULT_PORT
 from pagerite.chunks import chunk_key, needs_translation
 from pagerite.data import Data, Node, sorted_nodes
 from pagerite.segments import Span, join, split
@@ -194,19 +191,6 @@ def store_results(data: Data, lang: str, items: list[TransResult]) -> list[str]:
     return pages
 
 
-def log_service_urls(keys: dict[str, str], hostname: str) -> None:
-    """Log the translator WebSocket URL(s) for the admin at startup, one
-    line: "…/_translate/<key> (<name>)", comma-joined — ws:// with the port
-    on localhost, wss:// without a port on a public hostname (the port comes
-    from the CLI via the PAGERITE_PORT env). No-op without keys."""
-    if not keys:
-        return
-    port = os.getenv("PAGERITE_PORT", DEFAULT_PORT)
-    base = f"ws://localhost:{port}" if hostname == "localhost" else f"wss://{hostname}"
-    urls = ", ".join(f"{base}/_translate/{key} ({name})" for key, name in keys.items())
-    logger.info("Translator %s", urls)
-
-
 class _Connection:
     """One connected translator socket: the language codes it announced as
     capabilities (Hello) and the (lang, chunk-key) job currently in flight
diff --git a/scripts/translator.py b/scripts/translator.py
index da45764..04a119c 100644
--- a/scripts/translator.py
+++ b/scripts/translator.py
@@ -13,8 +13,8 @@
 """Pagerite translator service: translate site content with Seed-X-PPO-7B.
 
 Connects to a Pagerite server's translator WebSocket — the full URL
-including the access key (printed at server startup; the admin also finds
-the key in the site settings, GET /_api/settings -> ``translate_keys``) —
+including the access key (the admin finds the key in the site settings,
+GET /_api/settings -> ``translate_keys``) —
 and announces the languages the
 model CAN translate (capabilities). The server dispatches one single-item
 job at a time per connection, offered only in its configured target