Verifying a domain

Why we ask for this

Anyone can type a domain into a form. Proving you control it is what makes the rest of OutreachPal worth using. When a site in the directory is marked as verified, its owner proved control of it, not just claimed it.

Verification takes a few minutes and you only do it once per site.

Choosing a method

The methods are equally valid and none is worth more than the others. Pick whichever gives you the least trouble with the site you are verifying.

Your verification code stays the same whichever method you pick, so you can switch between them without starting over.

For the meta tag and the file, we try four addresses for you: https and http, with and without www. You do not need to worry about which one your site uses.

DNS TXT record

You add a text record to the domain's DNS settings.

Best when you have DNS access, and the only option that works on a site you cannot edit directly.

Slower than the others. DNS changes need time to spread across the internet, usually a few minutes and occasionally a few hours. Add the record and run the check. If it is not visible yet, you can come back and run it again, or simply wait: we also check pending domains once a day on our own and email you when yours goes through.

Your code is shown on the verification screen. Copy the whole value including the outreachpal-verification= part.

The part that trips people up. The @ means the domain itself rather than a subdomain, and every DNS panel spells that differently. Most accept @ typed literally. Some want the field left empty. A few want your full domain name. If your panel rejects @, try empty first, then the domain.

Where DNS settings live on the common providers:

• Cloudflare: pick the domain, then DNS, then Records, then Add record.
• GoDaddy: My Products, find the domain, DNS, then Add.
• Namecheap: Domain List, Manage, Advanced DNS, then Add New Record.
• Aruba: Pannello di controllo, Domini, Gestione DNS.

Meta tag

You add one line to the <head> of your homepage.

Best on WordPress or any CMS where you can edit the theme header, when you do not have DNS access. The check answers in a couple of seconds.

<meta name="outreachpal-verification" content="YOUR-CODE">

It has to be on the homepage, inside <head>, and visible to visitors who are not logged in. If the site is behind a staging password or a "coming soon" plugin, the check cannot see it.

File upload

You place a small text file on your server.

Best when you can reach the hosting file manager but not the theme or the DNS. Also fast.

The .well-known folder sits at the top level of your site and may not exist yet, in which case you create it. The file has to load at that exact address with no redirect. If your host serves a styled "page not found" screen instead of a real 404, the check will read that page instead of your file and fail.

Published page

You publish a page on your site containing your code, and paste us the address.

This is the one for people who can write on the site but cannot touch anything else. If you are an in house SEO or work at an agency, you probably publish articles through the CMS and have never seen the DNS panel or the theme files. The other three methods assume access you do not have. This one does not.

It still proves what it needs to prove, because publishing at an address on that domain is something only somebody with access to the site can do.

1. Pick Published page on the verification screen and copy your code.
2. Publish a page anywhere on the site. Any title, any slug, any template. A draft does not work, it has to be live.
3. Put the code in the visible text of the page. Not in a comment, not in a hidden field, not as an image.
4. Paste the page address back into the form.

We keep the address you gave us, so if the check fails you retry with one click instead of pasting it again.

The address has to be on the domain you are verifying. We accept the bare domain and the www version, and nothing else. A page on a subdomain such as blog.yourdomain.com will be refused, because controlling a subdomain does not prove you control the domain. If your blog lives on a subdomain, use one of the other methods.

When the check does not find it

The tag or file is definitely there and it still fails. Some sites sit behind a security or anti-bot layer, Cloudflare being the most common, which answers our check with an error instead of the page. Your visitors see the site normally, we do not. Nothing is wrong on your end.

Switch to the DNS TXT method. It reads the domain records instead of fetching a page, so the protection does not apply.

The DNS record is there but nothing happens. Give it time, propagation is genuinely slow sometimes. Then check how your panel wanted the @ written.

You just published the page and the check does not see it. Caching plugins and CDNs often keep serving the old version of a page for a while after you publish. Clear the site's cache if you can, then try again. This is the most common reason the published page method fails on the first attempt, and waiting a few minutes usually fixes it on its own.

Someone already verified this domain. One domain belongs to one owner. If another member proved control before you, the domain is taken. If you believe that is wrong, contact us and we will look.

After it succeeds

Once the site is verified, you can remove whatever you added to prove it. The TXT record, the meta tag, the file or the published page can all come down, and the site stays verified.

We measure the site's metrics automatically. What happens next depends on those numbers, and that is covered in Site requirements.

Adding a second site means a separate verification. Each domain is proven on its own.