Strange dns set up from square online not resolving

I have a website and online store with square online and so far they have given me three different sets of ip address and cname and txt to add to my dns records at cloudflare

When i am checking the propagation the www record is an a record

I have no idea what the txt is either

Checking the technology of the site of my domain it seems to be weebly with no mention of square online and robots.txt file is nothing like the urls of my website or store products

Cloudflare radar is also blocked from scanning the urls and I have no idea why


This text will be hidden

What is the domain, and what are the different sets of records that they asked you to add?

1 Like


Can you show a screenshot of this site, including the section “Cloudflare Nameservers”?

Square bought Weebly in 2018. Square Online is a new platform built on top of the of old Weebly technology. So if you’re using Square Online, seeing some references to Weebly wouldn’t be unexpected.

Have you tried setting up your domain by following their manual? It tells you to add one A record, one CNAME record and one txt record:
There should even be an automatic option to add these records to your Cloudflare account.

Edit: Also, what exactly are the problems you are facing right now? Just the incorrect sitemap?


Thanks, yes its just we only joined them in October last year, but each support person we talk to tells us something different. Yes we have always used the manual set up, its just that set up keeps changing and our domain kept disconnecting and when we try to reconnect it, it says its already connected to a site at square.

The problem we are having is our online store product urls are completely different in our robots.txt sitemap.xml (correction) file than they are on our live site

Also the dns hasnt propagated

The www is only a record not cname as entered

and cloudflare radar url scanner os forbidden from scanning the urls

I think there’s some misunderstanding here.

A robots.txt is not meant to list your site’s URLs. That’s the job of your site’s XML sitemap here:

The robots.txt tells search engine crawlers which URLs they can or cannot access on your site. And since search engines will crawl all URLs by default unless instructed otherwise, it’s typical for robots.txt files to only list URLs you don’t want search engines to crawl. And that’s exactly what yours is doing.

Your XML sitemap, on the other hand, lists your site’s URLs. Your shop has 10 products, and the URLs of all these 10 products are in the XML sitemap.


What exactly do you mean by this? What happens when your domain “disconnects”? Do you see any errors when you try to open it?

Where do they appear? In Google search results, or in your DNS records?

What do you mean by this? Any errors?

That is to be expected when the record is set to proxied.

That is because you seem to be using the Cloudflare Firewall to block automated requests to your site. Is this not intended? You can see which Cloudflare product caused the block here:

If this is not something you want, maybe switch both of your DNS records to DNS-Only instead of proxied.


sorry yes, the sitemap. It isnt our live site product urls in the sitemap. But its our product names, we have also noticed lots of changes made in this account, but the email address for the cloudflare account hasn’t been used for anything else and we immediately set up 2 factor auth on all accounts upon creating them, it would be impossible for anyone to guess the email address, its a random collection of letters, so its either that whoever is making the changes is already in cloudflare or they are somehow managing to remotely control the domain

If you look at the live site, you will see that the products urls are /s/shop/this-is an-example

but in the sitemap they are /product-a-different-url

Its only the actual name of the product thats the same, not the site urls

regards the autodiscover and en subdomains I am finding them in subdomain lookups

it seems a company called podia has somehow managed to add a plugin between our old webhost and stripe payments, so its possible its them that have set these subdomains up, looking at how their site works you have to add a subdomain to your domain, we have never created any subdomains or ever had any microsoft set up for email

podia have ignored our emails requesting to know how they have managed to convince stripe that we set up our stripe account via them and they have blocked us on social media

what we do know is, the website that our product checkout was redirecting to and the site that search console seemed to think was ours does have a podia account and has had one for a number of years, its just figuring how they accessed our website host, this has followed us over 2 different websites, we can see there are products on our google business listing that aren’t ours, so we cant remove them or edit them. We know podia have cloudflare because we can see their own technology, we can also see all the sites that have had sites with them, not one of them is our domain name or even remotely similiar to our domain name

Im starting to think they added our domains to cloudflare long before we even knew what podia was

Thats the thing, nothing happens, the site stays up but the domain isnt connected, oddly this also happened when were at wix with the same domain, looking back at our domain history, there are periods as long as a year where the domain wasnt connected to wix but google.

No, I don’t see that. Can you show a screenshot of that?

That’s what I see both on the sitemap and on your live site.

I don’t. Can you show where you find them? A screenshot maybe?

What does that mean? Either it’s working or not, it can’t be both. Or what do you mean by “connected”? Usually, this means that your site shows up when someone enters your domain.

Can you show a screenshot of this?

Right now, I’m really struggling to see any of the problems that you described. From my perspective, everything seems to be working.

1 Like

The urls have changed from what they were a few days ago

most subdomain checkers will show you the subdomains also shows there were certificates issued for those subdomains

Even if the domain isnt connected the website stays up, is exactly what I mean, the website doesn’t go down if its not connected to the site, at one point I couldn’t even connect the domain because square notice was saying the domain is already connected to another square site, for me to remove the domain from the other site to add it to this one

This also happened for over a year when the domain was supposed to be connected to wix, it turns out the site was actually connected to google, but the site didnt go down. When we were trying to disable any third party apps on the site, we couldnt delete a pages one, wix told us that was a third party app that we had connected (we had never heard of the pages app) we just assumed that it was part of wix until the woman said we had added it from a third party source

So it seems like somewhere along the line as we had been telling wix all along, someone else was editing our site and changing our product urls, putting in data images etc

You’re looking at historical information. From, the most recent certificate for was valid from 2022-02-01 and 2022-05-02. There’s no certificate for 2023 or 2024.

I don’t know what “subdomain lookups” tool you’re using, but I’ll bet you’ll see something similar if you look closely at the information in front of you. For instance, here’s one such report: | Subdomains Lookup | WhoisXML API

Sure, and are listed in the report… but look at the “Date of last report” for these two subdomains: October 5, 2021 and August 17, 2020 respectively. Contrast these with the “date of last report” for the 3rd subdomain April 6, 2024. The first two subdomains simply do not exist today, while the 3rd one exists.

From Securitytrail’s historical database, it seems (along with the main domain) was previously pointed at Wix, while was pointed at CloudCoCo (UK IT support provider).

Given the several pieces of information you’ve provided here which seem to be inaccurate (or so vaguely described that they’re meaningless), I’ll recommend you find a trusted local “tech” person to look into your site’s setup for you – as I fear you won’t accept anything we tell you here.

Good luck!


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.