In practice, this meant that an agent with a clear assignment, a plausible budget and a human available to help produced one usable candidate from two days of scheduled searches.
This does not mean that the portals block every AI system or that their listings are generally inaccessible. It shows how these services responded to one consumer agent working from its own cloud computer on 19 and 20 August 2026. We repeated the main requests from a residential internet connection to understand whether the failures came from the pages themselves or from the environment in which the agent was running [S2].
Why we ran the test
Grok Bot entered public beta on 11 August. Each bot runs on its own cloud computer and can continue working after the person who created it has closed their laptop [S5].
We were interested in it because the initial experience was unusually simple. We described the assignment in ordinary language, and within about two minutes the bot had proposed a workflow and started working. It did not need instructions on how to use a search engine or which German property portals might be relevant.
The brief was based on a realistic business need. We asked the bot to find a self-contained office for a small team in or around Munich's Maxvorstadt, with a monthly budget of roughly €1,000. We have removed identifying details that did not affect the test.
The agent began by clarifying what the budget should include and how far it could widen the search. It then decided to check ImmoScout24, Kleinanzeigen and Immowelt. It scheduled three searches a day, at 8:33, 14:33 and 20:33, and planned to report only when something changed [S1].
This was the part of the experience we found promising. The bot turned a short request into a sensible monitoring routine without requiring the user to design that routine first.
The problems began when it tried to carry it out.
What happened at ImmoScout24 and Kleinanzeigen
ImmoScout24 did not allow the agent to read its search results. The browser displayed a page saying that the visitor had been mistakenly detected as a robot. There was no visible checkbox or other challenge the agent could complete [S1].
The bot paused and asked a human to take over. This is generally the right behaviour when an agent encounters a step that requires human approval or input. In this case, taking over did not help because the browser continued to show the same block page.
We also sent a direct request to the search URL. The server returned 401 Unauthorized, but did not provide the authentication challenge that would normally tell a client how to proceed [S2].
Kleinanzeigen stopped the agent earlier. Requests from the address range used by its cloud computer returned 403 Forbidden. The block covered the site's listings as well as its robots.txt file, so the agent could not read either the content or the site's published instructions for automated visitors [S2].
We repeated the Kleinanzeigen request from an ordinary residential connection. The same page returned successfully. From the agent's cloud environment, it remained blocked.
This suggests that Kleinanzeigen was responding to the origin of the request rather than to anything the agent had done on the site. Our probes consisted of individual requests at human pace. The agent had not produced the volume of activity normally associated with bulk collection.
The bot recorded both portals as unreadable. It did not interpret the absence of results as evidence that no suitable offices existed. That was an important distinction because the agent had no information about the listings behind either block.
What happened at Immowelt
Immowelt allowed the agent to search and read listings. This made it the only one of the three large portals in the test that the bot could use without human intervention.
The search page reported 285 offices in Maxvorstadt. That number remained unchanged across three scans over two days [S1].
As the agent reviewed the results, it found that many of the offers did not match the ordinary meaning of a small, self-contained office. Some were individual desks in coworking spaces. Others were rooms in serviced business centres. All of them appeared within the same office category.
The floor-area figures also required interpretation. One offer advertised 75 square metres, of which 50 were private and lockable. Another advertised 27 square metres for a room with 18 square metres of private space. Shared areas had been included in the larger figures.
This is useful information for a human who reads the full description. It is less useful as a field for comparing listings because the number does not describe the same thing in every offer.
The agent also continued to see a listing marked as reserved. There was no filter for separating a self-contained unit from a coworking desk, even though that distinction was central to the assignment.
After applying the brief to the available results, Grok Bot retained one candidate.
Why the published policies did not resolve the problem
After the first searches failed, we examined the public files and documentation that explain how automated systems may access the portals.
ImmoScout24's robots.txt explicitly names GPTBot, ChatGPT-User, ClaudeBot and PerplexityBot. These crawlers are broadly allowed to access the site, apart from a restricted price-index section. The office search is not listed as disallowed [S2].
A robots.txt file governs crawlers. It does not automatically grant access to every AI product, and Grok Bot was not acting as a crawler in this test. It was performing one assignment for one user.
This leaves consumer agents in an unclear category. They are automated, but their purpose can be closer to that of an individual customer than to that of a search engine or a company collecting listings in bulk. The published policy did not provide a route for that kind of request, while the live service rejected it.
The official ImmoScout24 search API does not currently provide an alternative for this use case. Its documentation says that the API is available only to content partners and is not intended for data-delivery use cases [S3].
Immowelt publishes an llms.txt file containing 1,854 links across 346 kilobytes. All of the links point to editorial guides. None points to a property listing [S4].
This may still make Immowelt's general information easier for AI systems to discover. It does not help an agent with a current property search.
Across the three portals, we found three separate access questions. The first is what the published policy permits. The second is what the server or security layer allows through. The third is whether the returned content contains information the agent can use reliably.
A site can perform well on one of these questions and poorly on another. Immowelt returned readable pages but lacked consistent fields for the assignment. ImmoScout24 published permissive rules for several prominent AI crawlers but did not allow this agent to reach the search results. Kleinanzeigen blocked the agent before it could read either the listings or the policy file.
We also tested ShareDnC, a smaller site for flexible office space. It did not publish special instructions for AI agents, but returned a complete listing in the first response [S2].
| Portal | Published policy | Network edge | Content returned |
|---|---|---|---|
| ImmoScout24 | Named AI crawlers allowed | 401 with a block page, no challenge to complete | None. Zero listings in two days. |
| Kleinanzeigen | Unreadable: the policy file itself returned 403 | Cloud address range blocked; residential connection served | None from the agent's environment. |
| Immowelt | Search endpoints disallowed; llms.txt lists guides only | Search page open, server-rendered | Listings, with mixed unit types and inconsistent area figures |
| ShareDnC (smaller flex-office site) | No special instructions | Open | A complete listing in the first response |
Single GET requests, 19–20 August 2026, curl and Chrome user agents, datacenter and residential egress. Full probe detail in the JSON version of this article. [S2]
Why portals block this traffic
Property portals have good reasons to protect their listings. Inventory can be copied, republished or collected for competing services. Blocking requests from datacentre address ranges is one way to reduce that activity.
The difficulty is that consumer agents often run in the same cloud environments. A service therefore has to distinguish between two requests that may look similar at the network level: one from a system collecting large amounts of data, and one from an agent checking a small number of listings for an individual user.
The difference is intent, but the controls we encountered did not ask about intent. Kleinanzeigen responded differently according to the network from which the request arrived. ImmoScout24's block page described the detection as a possible mistake, but did not provide a usable recovery path.
Our bot was running a test, not negotiating a lease. A future agent acting for a genuine prospective tenant could nevertheless arrive from the same infrastructure and receive the same response.
This matters because the portal may never see the result as lost demand. The agent does not necessarily reach a listing, open a contact form or appear as an abandoned enquiry. From the business's perspective, little has happened. From the user's perspective, an entire source of supply may have disappeared from the search.
What an agent-accessible property search would require
A portal would not need to make all of its inventory freely available to every automated system. It would need a controlled way for an agent to search on behalf of a person.
One approach would be an authenticated search interface with clear limits on frequency, scope and permitted use. The user could authorise the agent in much the same way that a person authorises an application to access a calendar or email account.
A change feed would also be more efficient than having an agent reload the same search page several times a day. Property portals already send saved-search alerts to people. A machine-readable version could notify an authorised agent when a listing is added, changed, reserved or removed.
The listing data would need to distinguish between figures that currently require a human to interpret. For this assignment, the relevant fields included private floor area, shared floor area, total rent, additional charges, unit type and current availability.
These changes would also make the search clearer for human users. The agent exposed the problem because it could not infer reliably what an experienced property seeker might work out from photographs, descriptions and context.
What this test shows
This was a limited field test involving one agent, one brief and a small number of portals. The results may change as the portals update their security systems or as Grok Bot changes the way it accesses websites. They should not be read as a general assessment of the quality of the companies or their services. We have no relationship with any of the portals named here, or with SpaceXAI.
The test does show that publishing rules for AI crawlers is different from supporting an agent that acts for a customer. It also shows that successful page access is only part of the task. The content must contain fields that allow the agent to apply the user's criteria without guessing.
We expect this distinction to become more important as consumer agents become easier to set up. Grok Bot required little technical knowledge to turn the office brief into a recurring search. The user experience was ready before much of the market infrastructure it depended on.
We will continue to run the same probes and record when the results change.