Safari "Deceptive Website" warning persists after hosting migration — correct escalation path?

Question

Created 22h

Replies 4

Boosts 0

Participants 2

Five of my sites are flagged by Safari's Deceptive Website Warning. They are legitimate and none of them collect credentials, imitate another brand or contain social engineering content:

store-api.ru — paid access to third-party AI APIs (clearly states it is not affiliated with OpenAI, Anthropic or Google)
cenwise.ru — price comparison service
kirillportfolio.ru — personal developer portfolio (no login, no forms, no data collection at all)
3021.ru — habit tracking app
animegenai.ru — AI image generation service

All five are clean in Google Safe Browsing, Google Transparency Report, Google Search Console and Yandex Webmaster. Safari is the only place showing a warning.

The flag appears to be inherited from a previous hosting provider whose IP ranges had reputation problems, and it seems attached to the domain names rather than to the current infrastructure. This is directly testable:

On 20 July 2026 all sites were migrated to a new host — a single server, single IP (152.53.119.191).
On that exact same server and IP, the domains created AFTER the migration are NOT flagged: filelama.com (live since 28 July, fully indexed), novelisstory.ru (25 July) and store-api.com (4 August).
Only the domains that already existed under the previous host are still flagged.
Same server, same IP, same certificates, same kind of content. The only variable is whether the domain existed before 20 July.

store-api.ru and store-api.com are the clearest case: both are literally the same application behind the same nginx on the same IP, differing only in the domain name. The .ru is flagged, the .com is not.

I submitted requests through websitereview.apple.com on 20 July and again on 11 August 2026. Neither produced a response or an acknowledgement, which as I understand is expected behaviour for that form.

My questions:

Is websitereview.apple.com still the correct — and only — channel for a site owner to dispute a false positive?
Is there any way to confirm that a submission was received, or a typical review timeframe I should expect?
Would a Feedback Assistant report under Safari add anything here, or would it simply duplicate the request?

Answer 1

DTS Engineer OP

Apple

20h

Thanks for the post, on the error page, as you already know, you can click/tap the link to https://websitereview.apple.com/

If you believe your website has been incorrectly identified as a deceptive website, you can request that it be reviewed. The warning may be removed if we determine the issue has been corrected.

https://websitereview.apple.com/?tpl=safari&url=http%3A%2F%2Fstore-api.ru%2F&hl=en-US

For your question 1, these are the correct way to ask to be reviewed. For 2 there is a confirmation page when you submitted a website. And to answer 3 the Feedback Assistant will just let you know about the website to review.

I would like to add that is important to provide on the box actionable information as unfortunately, there is no way to confirm receipt externally. The websitereview.apple.com portal acts as a one-way submission queue and does not send automated acknowledgements or status updates, so if you do not provide any actionable item, the website will remained without changes.

Hope this helps.

Albert  WWDR

Answer 2

Saymy9ame OP

13h

Accepted Answer

Thank you Albert, this is very helpful — especially the point about providing an actionable item, which I had not understood that way before.

One data point that may be useful for others reading this: submissions through websitereview.apple.com do produce an automated acknowledgement by email. I received a message titled "Your review request was received" for each submission I made on 11 August 2026. So receipt can at least be confirmed that way, even if there are no status updates afterwards.

That leads to my follow-up question. In my case nothing in the site content ever caused the flag. The sites were flagged while hosted with a provider whose IP ranges had reputation problems, and the very same content, on the same server and the same IP, is not flagged for domains that were created after I migrated away on 20 July 2026.

So there is no content change I can point to as "corrected" — what was corrected is the hosting.

What would count as an actionable item in a case like this? Is stating the migration date and the new IP sufficient, or is there something specific the review team looks for when the cause is infrastructure reputation rather than page content?

Thanks again for taking the time.

Answer 3

DTS Engineer OP

Apple

2h

Thanks for the reply.

For your "actionable item," the best thing you can do is provide concrete proof of your domain ownership alongside the evidence of your migration to the new hosting provider.

As a quick piece of advice when you submit this information: please write the submission directly and avoid using AI tools to generate the request. In my personal opinion I found that AI generated messages often omit the actual proof and specific. Just providing your own clear evidence of the domain and hosting migration is exactly what they are probably looking for. Again a personal suggestion only because I do not work on that team nor I am involved in anyway.

Albert  WWDR

Answer 4

Saymy9ame OP

1h

Good evening, Albert. Thanks so much. Google Search Console, from aeza domain migration.The timewebcloud. VPS on netcup. I am attaching Screenshot. The screenshot is my netcup account. Server IP is 152.53.119.191. The uptime shows the server is running since 20 July 2026 — that is the day of the migration.The Timeweb Cloud screenshots are from August 2026 — that is a later change of DNS provider, not the hosting migration. I attach them as proof that I control the domains.