How Indexly works

Without owner or full access, Google gives us no information about your pages and accepts no requests on your behalf. With view-only rights we can see the website listed, but do nothing with it.

Because Google caps the Indexing API at 200 submissions per day per Cloud project, for the whole project and not per website. If every customer shared our project, that quota would be gone after a handful of websites. With a project of your own those 200 are yours. It costs you nothing, as Google's API is free, and the wizard in the dashboard walks you through the steps: create a project, upload a service account key, enable the Indexing API and add the service account as an owner in Search Console. Without this project we cannot submit anything; checking what is missing carries on as normal. We stay under that with a margin of our own: 180 submissions a day for your whole account, and at most 50 per website — so one site cannot drain the project at the expense of the others.

Then we can only work with the pages Google already knows, which means we cannot see what is missing. A sitemap is the only reliable source of 'what should be there'. Almost every CMS generates one automatically.

Google decides that, and it varies a lot per website and per page. We record when we submitted a page and when we first see it in the index, so you can follow it yourself rather than having to take our word for it.

No. After five attempts we stop with that URL. If a page still is not indexed after five tries, the cause is the page itself and not the submitting — continuing only burns capacity another page could use.

One text file holding a key, on your own domain, so the search engines can establish that a notification really comes from the owner. Nothing else: no Cloud project, no service account, no plugin. After that, changes travel to Bing, Yandex, Seznam, Naver and Yep automatically.

We fetch the page and compare a fingerprint of the parts that matter for indexing: the title, the meta description, the canonical, the robots directive, the first H1, the main content and the structured data. Navigation, footer and dates are deliberately left out, because they change on every visit and every page would always look changed.

Because that is not a new signal. Announcing the same page again while nothing changed spends daily quota that a genuinely new or updated page can put to better use. If something does change later, the comparison picks it up by itself.

They are our observations, not snapshots from Google. Apart from the crawl moment, which Google reports itself, the rule is the same everywhere: we know when we first saw something, not when it happened. The real event sits between the previous check and that observation, so accuracy depends on how often we check. Recently changed pages come up more often than the rest.

When the number of indexed pages has fallen by at least 5 pages and at least 2% compared with the previous measurement. Both conditions have to hold: a percentage on its own makes a small website cry wolf at every ordinary fluctuation, and a count on its own lets a real loss on a large website disappear into the noise. That is the threshold for what you see on your dashboard, per website and against the previous measurement. The email has its own, higher threshold: at least 3 pages and at least 5%, counted across your whole account and compared with a week earlier, at most one message of each kind a day. That keeps the dashboard fine-grained while your inbox stays quiet.

That we managed to check noticeably fewer pages than usual that day, for instance because a daily quota at Google ran out. The fall you are looking at may then come from our measurement rather than from the index. We do not measure Google's index itself; we measure what Google reported to us at our last check. That is why every alert states how many pages were actually checked: with that figure in hand you can judge for yourself whether the fall is worth investigating.

Because they are three breakdowns of the same loss, not three separate losses. Every page that disappeared sits in a folder, came from a sitemap file and carries a reason from Google, so it counts in all three. Adding them up gives you roughly three times the real number. Compare within one breakdown, never across them.

It is a number from 0 to 100 that we build ourselves, not a mark from Google. Every page starts at 100 and each finding takes a fixed number of points off: a canonical pointing at another URL costs 30 points, a page with no internal links pointing at it 25, missing structured data 5. Every page carries the full list of deductions with their weight, so you can check the number yourself. Pages with a noindex, a robots.txt block or a 404 work differently: those cannot get in at all and receive a ceiling of 5 rather than a deduction, so they can never end up above a healthy page.

No. That needs a headless browser and we do not have one; we read the HTML as it reaches us. What we do is flag the risk: little text in the HTML plus a lot of script produces the finding 'possibly built by JavaScript'. That is explicitly a suspicion — what stands on the page after that script has run is something we have not seen, and Google does render, so it may see more than we do. This is why the finding carries only 10 points and why the dashboard labels it a suspicion.

Because we have not checked them yet. A page we have never asked Google about and have never fetched ourselves gets no number: not zero, not fifty. Those pages are counted separately and stay out of the average, the median and the list of worst pages. Inventing a score would only say that we have not done anything yet, which is no statement about your page.

Most likely because we have not seen enough of your website yet. We only count incoming internal links once we have fetched the HTML of at least 60% of your pages. The content check works through a website over days, so after the first round we know the links of only a small part — and counting then would declare nearly your whole website orphaned. The dashboard shows what percentage we are at right now.

No. The signals come from the same fetch we already make to work out whether a page changed in substance; no second pass goes over it. We fetch with an identifiable user agent, honour your robots.txt and never approach your server faster than needed.