Hva er NLWeb?

En praktisk gjennomgang av NLWebs API for naturlig språk, MCP-støtte, dagens referanseimplementasjoner og hva et Lovable-prosjekt fortsatt må løse selv.

NLWeb er et åpent prosjekt for nettsteder som vil tilby søk og svar med naturlig språk. En besøkende kan stille spørsmål om innholdet, mens en AI-klient kan bruke mye av den samme funksjonen gjennom Model Context Protocol, forkortet MCP.

Microsoft presenterte prosjektet under Build 2025. Koden og de tilknyttede prosjektene ligger nå hos GitHub-organisasjonen nlweb-ai (https://github.com/nlweb-ai), ikke under Microsoft-organisasjonen. Hovedimplementasjonen er skrevet i Python. Det finnes også en egen .NET 9-implementasjon (https://github.com/nlweb-ai/nlweb-net). Begge bruker MIT-lisensen.

Det er likevel for tidlig å omtale NLWeb som en ferdig webstandard. README-filen beskriver referansekoden som en demonstrasjon av én mulig løsning, ikke som den endelige arkitekturen alle skal følge. Den formelle TypeSpec-beskrivelsen står på versjon 0.5. Jeg ville derfor behandlet NLWeb som nyttig teknologi å prøve ut, med rom for endringer underveis.

Hva skjer når noen stiller et spørsmål?

Python-implementasjonen har /ask for spørringer med naturlig språk og /mcp for MCP-klienter. Selve spørsmålet er påkrevd. I tillegg kan klienten avgrense søket til et bestemt nettsted, sende med tidligere samtalekontekst, velge svarmodus og bestemme om svaret skal strømmes.

Den nyere TypeSpec-beskrivelsen definerer også Who-meldinger for agentoppdagelse. De skal hjelpe en klient med å finne hvilken agent eller hvilket verktøy som kan besvare spørsmålet, før den sender en Ask-forespørsel. Derfor er det lurt å kontrollere dagens protokollfiler fremfor å stole på den opprinnelige oppsummeringen med to endepunkter.

Dokumentasjonen beskriver tre moduser:

list returnerer de mest relevante treffene
summarize legger et sammendrag ved siden av trefflisten
generate bruker RAG, altså henting kombinert med en språkmodell, til å lage et fyldigere svar

Resultatet kommer som JSON. Et treff kan inneholde URL, navn, kilde, relevanspoeng, en generert beskrivelse og det opprinnelige strukturerte objektet. Prosjektet bruker Schema.org som vokabular når det passer dataene.

/mcp pakker den samme søkefunksjonen inn for MCP-klienter. Dermed kan en agent bruke nettstedets søk som et verktøy. Det betyr ikke at ChatGPT, Claude eller en annen tjeneste automatisk finner og stoler på alle NLWeb-installasjoner. Klienten må fortsatt støtte tilkoblingen, og miljøet kan kreve autentisering eller godkjenning.

README-filen nevner også støtte for A2A på et senere tidspunkt. Der står det «soon». A2A er derfor en plan, ikke en funksjon jeg ville lovet i en produksjonsløsning i dag.

Dette består løsningen av

Et lokalt prøveoppsett trenger mer enn to endepunkter. Den offisielle «hello world»-guiden bruker Python 3.10 eller nyere, en språkmodell, en modell for embeddings og en lokal Qdrant-database. Først laster du inn strukturerte data, beregner embeddings og lagrer dem. Deretter starter du webserveren.

Når et spørsmål kommer inn, kan implementasjonen tolke det i lys av tidligere spørsmål, hente aktuelle treff, rangere dem på nytt og eventuelt bruke en språkmodell til å oppsummere eller formulere et svar. Oppsettet er konfigurerbart og låser deg ikke til én leverandør.

Dagens repository dokumenterer blant annet OpenAI, Anthropic, Gemini, DeepSeek, Inception og Hugging Face for språkmodeller. For søk og lagring finnes valg som Qdrant, Postgres, Milvus, Snowflake, Azure AI Search, Elasticsearch og Cloudflare AutoRAG. Fleksibiliteten er fin, men hver tjeneste gir også flere nøkler, kostnader og driftsoppgaver å holde orden på.

Prosjektet er tydelig på hva som mangler for produksjon. Ferdige CI/CD-løp følger ikke med. README-filen anbefaler også at produksjonsløsninger bruker sitt eget grensesnitt og kobler seg til levende databaser fremfor å kopiere alt inn i en separat indeks. Ellers kan svarene bli utdaterte.

Schema.org er nyttig, men innholdet lastes ikke inn av seg selv

Den forrige versjonen av denne gjennomgangen ga inntrykk av at NLWeb automatisk leser all Schema.org-data fra nettstedet. Slik er ikke referanseimplementasjonen dokumentert. Du trenger en eksplisitt innlasting eller en kobling til en levende datakilde.

Verktøyet for databaseinnlasting godtar strukturert JSON, URL og JSON separert med tabulator, CSV og RSS- eller Atom-feeder. Deretter beregner det embeddings og skriver dem til valgt søkebackend. En produksjonsløsning kan i stedet hente data direkte fra databasen.

God JSON-LD på nettsidene er fortsatt nyttig, men den er verken en garanti eller et absolutt krav for at NLWeb skal fungere. Det avgjørende er at dataene tjenesten faktisk mottar er strukturerte, korrekte, oppdaterte og relevante for spørsmålene du vil besvare.

For en nettbutikk kan dette være produktnavn, beskrivelse, pris, valuta, lagerstatus og kanonisk URL. Det synlige innholdet bør stemme med den strukturerte posten. Googles Rich Results Test kan hjelpe deg å kontrollere produktmarkeringen. En godkjent test beviser likevel ikke at NLWebs innlasting eller datakobling virker. Det må testes separat.

Hva betyr dette for Lovable?

Lovables nåværende dokumentasjon viser ingen innebygd NLWeb-integrasjon. SEO- og AI-søkrapporten kontrollerer strukturert data, og publiserte Lovable-nettsteder kan tilby en ryddig Markdown-versjon til AI-crawlere. Det er nyttige grunnarbeider, men det er ikke det samme som en NLWeb-tjeneste.

For et Lovable-prosjekt ville jeg delt jobben i to:

Sørg for at synlig innhold, JSON-LD og kildedata er riktige.
Kjør NLWeb som en egen backend, eller bygg en backend mot den formelle protokollen. Eksponer bare dataene og handlingene som faktisk skal være tilgjengelige.

Ikke gjør administrasjonsdata eller personopplysninger tilgjengelige bare fordi MCP gjør et verktøy kallbart. Legg på autentisering der det trengs, ratebegrensning, logging og tester for utdaterte eller feilaktige svar.

Start gjerne smått. Last én pålitelig feed eller produkteksport inn i den lokale referanseimplementasjonen. Still ti spørsmål du allerede kjenner svaret på, og kontroller både teksten og de strukturerte objektene som følger med. Da ser du raskt om dataflyten holder, før du vurderer et offentlig endepunkt.

Kilder kontrollert

NLWebs Python-implementasjon og README (https://github.com/nlweb-ai/NLWeb)
Dokumentasjon for NLWebs REST-API (https://github.com/nlweb-ai/NLWeb/blob/main/docs/nlweb-rest-api.md)
NLWeb TypeSpec, protokollversjon 0.5 (https://github.com/nlweb-ai/nlweb-typespec)
Microsofts kunngjøring fra Build 2025 (https://blogs.microsoft.com/blog/2025/05/19/microsoft-build-2025-the-age-of-ai-agents-and-building-the-open-agentic-web/)
Lovables dokumentasjon for SEO og AI-søk (https://docs.lovable.dev/features/seo-aeo)