---
title: "Technical SEO issues hurting your website: find them, get alerts"
description: "Technical SEO issues can hide after a plugin update or redesign. Check Page indexing and URL Inspection tonight, set up email alerts, and plan the recovery."
url: "https://webleveling.com/blog/website-quietly-breaking-its-own-seo/"
lang: "en"
published: "2026-10-08"
modified: "2026-10-08"
author: "Cal Hewitt"
tags: ["seo","website-maintenance","small-business"]
image: "https://webleveling.com/og/blog-website-quietly-breaking-its-own-seo.jpg"
alternates:
  es: "https://webleveling.com/es/blog/errores-tecnicos-seo-que-danan-su-sitio-web.md"
---

# Technical SEO issues hurting your website: find them, get alerts

Technical SEO issues can hide after a plugin update or redesign. Check Page indexing and URL Inspection tonight, set up email alerts, and plan the recovery.

![A closed laptop, a small padlock and a stack of blank index cards on a wooden desk.](https://webleveling.com/blog/website-quietly-breaking-its-own-seo/technical-seo-issues-quiet-breakage-featured.jpg)

Your site opens fine on your phone. The pages look right, the contact form is there, and yet the calls have slowed since the last update, the plugin change or the redesign. The unsettling part is that nothing on screen tells you whether Google can still use the pages. A visitor with the link sees a working site; Google may be seeing a "do not index" instruction, a blocked folder or a redirect that goes nowhere. The good news is that you can check this tonight, for free, inside Google Search Console.

**Key Takeaways**

**Check Search Console first**

The Page indexing report and URL Inspection show whether Google is allowed to crawl and index your homepage and your most important service page.

**Five breakages come up again and again**

A noindex or visibility setting left on, a robots.txt block, a wrong canonical tag, redirects that are missing or broken, and password or private-site status.

**Robots.txt is not a delete button**

It controls crawling, and a blocked page can still show up in Google if other pages link to it; noindex is the instruction for keeping a page out, and Google has to be able to crawl the page to see it.

**Emails are a start, not full coverage**

Search Console emails you about important events, so pair the email setting with a ten-minute monthly check and a check after every site change.

**Recovery takes days, not minutes**

After a fix, run the live test, request indexing for key pages, resubmit the sitemap if many pages changed, and give it at least a week before judging the result.

## What can you check tonight to see if Google can still use your site?

Start with two screens in Search Console, because they answer the question directly. First, make sure you are in the right property, meaning the exact address of your live site. Then open the Page indexing report and look at the reasons listed under Not indexed. You are looking for anything that does not match your intentions, such as "URL marked noindex," "URL blocked by robots.txt," "Page with redirect," "Redirect error" or server errors. A handful of pages in these lists can be normal, since Google says duplicate, filtered, private or deliberately blocked pages may be excluded for good reasons. A pattern that covers your service pages or your homepage is not normal.

Next, paste your homepage address into the URL Inspection bar, then do the same for your most important service page. In the result, confirm four things: crawling is allowed, indexing is allowed, the page fetch is successful, and the canonical page Google picked is the one you expect. [Google's Search Console help on indexing and inspection](https://support.google.com/webmasters/answer/7440203) explains each of these results.

![A closed laptop beside a small stack of blank index cards and a pencil on a wooden desk.](https://webleveling.com/blog/website-quietly-breaking-its-own-seo/search-console-check-desk.jpg)

Two reports and two URLs: that is the whole first check.

If both pages pass, your problem is less likely to be a switch that got flipped and more likely to be ordinary ranking, demand or season. Our post on [what to do when your site is not showing up on Google](https://webleveling.com/blog/website-not-showing-up-on-google/) picks up from there. If something fails, the usual causes are next.

## Which silent breakages are worth looking for first?

An update does not announce itself when it changes how Google sees your site. The same edit that makes a page look better can add an instruction that tells Google to skip it. The causes below are listed in a practical order for checking: the ones that remove the most pages at once come first.

Each of these can be grouped by what Google experiences. Some pages are blocked (Google is told to stay away or not to list them), some pages are missing (the address no longer leads anywhere useful), and some pages are erroring or slow. Sorting what you find into those three groups keeps the repair simple.

### A noindex or visibility setting left on

A noindex instruction tells Google not to show a page in search. [Google's documentation on blocking indexing](https://developers.google.com/search/docs/crawling-indexing/block-indexing) says Google needs to be able to crawl the page to see that instruction. It is the right tool when you want a page hidden, and it is a disaster when it stays on a page that should earn calls. It gets left on after a launch, after a move from a staging copy, or by a setting that applies to the whole site.

### A robots.txt block

Robots.txt is a small file at the root of your site that tells crawlers which areas to stay out of. A rule that made sense on a test copy, or a single wrong line, can block a folder of service pages. Keep one point in mind: [Google explains that robots.txt controls crawling](https://developers.google.com/search/docs/crawling-indexing/robots/intro) and is not a dependable way to remove a page from search results. The standard behind it, [RFC 9309](https://www.rfc-editor.org/rfc/rfc9309), describes it as instructions for crawlers and not as a lock. Our post on [whether your website needs a sitemap and robots.txt](https://webleveling.com/blog/does-your-website-need-a-sitemap-and-robots-txt/) covers the file itself.

### A canonical tag pointing the wrong way

A canonical tag names the preferred address when several addresses show the same content. After an edit, templates sometimes point every page to the homepage, to a staging address, or to the unsecured version of the site. [Google treats the canonical as a hint](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) and may choose a different address, but a tag that points the wrong way can still push good pages out of search results.

### Redirects that are missing or broken

If a redesign changed your page addresses, every old address needs a permanent redirect to the closest new page. When that step is skipped, old links and old search listings land on error pages. Redirect chains and loops cause trouble too, and so does a pile of old addresses all sent to the homepage. Our guide to [moving a website without losing Google rankings](https://webleveling.com/blog/moving-your-website-without-losing-google-rankings/) shows how to map them.

### Password or private-site status

Private or password-protected status is meant for a site under construction. When it stays switched on, nobody outside the password can see the pages, Google included.

Silent breakages, where they hide and how to spot them

| Breakage | Where it hides | Search Console sign |
| --- | --- | --- |
| Noindex or visibility setting left on | CMS reading or SEO settings, page-level SEO plugin fields, staging copy | "URL marked noindex" in Page indexing |
| Robots.txt block | The robots.txt file at your site's root | "URL blocked by robots.txt" |
| Wrong canonical tag | Page templates and SEO plugin settings | URL Inspection shows a different Google-selected canonical |
| Missing or broken redirects | Server or plugin redirect rules after a URL change | "Page with redirect" or "Redirect error," plus old links landing on error pages |
| Password or private-site status | Platform site availability settings | Page fetch fails in URL Inspection |

## Which settings on WordPress, Wix and Squarespace cause the first of these?

Most of the sitewide switches have a name and a location you can find in a minute. These are the ones the platforms document, and the menu labels below are the ones their help pages use. If your dashboard differs, the platform has probably renamed something, so search its help for the same phrase.

On WordPress, go to Settings, then Reading, and look at Search Engine Visibility. The box labeled "Discourage search engines from indexing this site" tells search engines to stay away, and [WordPress documents this setting](https://wordpress.org/documentation/article/settings-reading-screen/) as generating a noindex instruction when the normal header hook is present. This box is commonly ticked on a development copy and carried across to the live site. SEO plugins add their own controls too: for example, [Yoast lets you set individual pages and categories to noindex](https://yoast.com/help/how-do-i-noindex-urls/), so a page-level setting can hide one service page while the rest of the site looks fine.

On Wix, the site-wide switch is in the dashboard under SEO & GEO, then Tools and settings, then SEO Settings, where "Let search engines index your site" can be turned off. [Wix explains how to enable search engine indexing](https://support.wix.com/en/article/enabling-search-engines-eg-google-to-index-your-site), and individual pages have their own visibility controls.

On Squarespace, look at Site Availability, which can be Public, Private or Password Protected. [Squarespace describes publishing and hiding your site](https://support.squarespace.com/hc/en-us/articles/360002088548-Publish-or-hide-your-site) and also [how page-level passwords and noindex controls work](https://support.squarespace.com/hc/en-us/articles/360022365512-Controlling-who-can-access-your-site-s-pages).

![A small wooden ruler and a brass padlock resting on a folded sheet of blank paper.](https://webleveling.com/blog/website-quietly-breaking-its-own-seo/visibility-switch-padlock.jpg)

One switch, left in the wrong position, can hide a whole site.

If you run a staging copy for testing, treat it as a separate site with its own rules. Staging systems often carry noindex, password protection or robots blocking, and those settings should never travel to the live site when you publish. A short launch note listing the visibility setting, the robots.txt file and the canonical tags saves a lot of guesswork after each release.

## How do you get warned next time instead of finding out weeks later?

Set up the email alerts first, then add a routine that does not depend on them. Both take less time than a cup of coffee.

Verify your site as a property in Google Search Console if you have not already. From any Search Console page, open User settings, then Email preferences. Keep "Enable notification by email" turned on and subscribe to the message types that apply. These email settings belong to you as a user and apply across the properties you can access. It also pays to make sure the person who receives the emails is someone who will read them, and that the business, not a former developer, controls access to Search Console. Our post on [what Google Search Console emails mean](https://webleveling.com/blog/google-search-console-emails-explained/) explains the common messages.

Now the part that matters most: Search Console emails you about important events such as manual actions and security issues. It is not built as a guarantee that every accidental noindex, canonical or redirect error will trigger a message. Treat the email as your first line and the routine below as your backstop.

The monthly check takes about ten minutes. Open the property overview and read the security, manual actions and performance sections. Open Page indexing and look for a jump in Not indexed pages, especially for the reasons listed earlier. Inspect your homepage and your two or three most important pages with URL Inspection. Open the Sitemaps report and look for errors. Google's own getting-started guidance says many site owners need only this kind of quick check unless an alert arrives.

1.  1

    Right after any site change

    Inspect the homepage and one important page; confirm crawling and indexing are allowed.

2.  2

    Within a week of a launch or redesign

    Check Page indexing for new reasons under Not indexed, and read the Sitemaps report.

3.  3

    Monthly

    Read the overview, Page indexing, URL Inspection on key pages and the Sitemaps report.

4.  4

    Whenever an email arrives

    Open the message in Search Console and inspect the pages it names.

Pick a day of the month, put it on the calendar, and keep it. A check that happens on a set date gets done; one that waits for a worry usually does not.

![A paper wall calendar with one square circled in pencil beside a closed notebook.](https://webleveling.com/blog/website-quietly-breaking-its-own-seo/first-of-month-circled-date.jpg)

A fixed monthly date makes the check a habit rather than a reaction.

## How long does recovery take once you fix the problem?

After you remove a wrong noindex, unblock a URL, correct a canonical, repair redirects or restore public access, test the live address in URL Inspection. If the live test shows the problem is gone, choose Request indexing for each important page. If many pages changed, submit or resubmit your XML sitemap in Search Console. [Google's help on inspecting a page and requesting indexing](https://support.google.com/webmasters/answer/12482179) is the place to confirm the current steps.

Then wait, and keep a note of what you changed and when. Google says indexing can take a few days, and for pages that are missing it suggests allowing at least a week after a sitemap submission or an indexing request before assuming the fix failed. Traffic often takes longer to return than indexing does, because Google has to recrawl and reassess the pages. Requesting indexing again and again does not help; fixing the cause does. A sitemap is a way to tell Google about your pages; it does not guarantee they are indexed.

The sites that recover cleanly tend to share a few habits: they know which pages earn calls, they keep Search Console access under the business's control, and they test the key pages after each change. If you use IndexNow to notify some other search engines when pages change, [what IndexNow does and whether you need it](https://webleveling.com/blog/what-is-indexnow-and-do-you-need-it/) is a separate question, because Google does its crawling through Search Console and its own systems.

![A stack of three folded blank pages tied with string next to a small brass key.](https://webleveling.com/blog/website-quietly-breaking-its-own-seo/recovery-record-folder.jpg)

A dated note of what changed makes recovery easy to measure.

## What can an owner fix alone, and when does paid help make sense?

You can do the first inspection yourself. Reading "URL marked noindex" and unticking a visibility box in WordPress does not require an agency. Many cases end there, and a good vendor would tell you so before selling you a large package.

Help starts to make sense when the cause is spread across several layers: page templates, SEO plugins, server headers, robots.txt, redirects, DNS, hosting and the deployment process. It also makes sense after a large migration, for a site with many pages that earn revenue, or when you want someone accountable for ongoing monitoring and for checking the site after every change. A professional can find the real cause, fix it without creating a second problem, test a sample of addresses, document the change and set up a repeatable check. That cuts diagnosis time and protects the next update. It does not guarantee rankings, traffic or instant reindexing.

Can an AI chat do the audit for you? It can explain what noindex or a canonical tag means, but it cannot see your Search Console data or your live settings. Your own Page indexing and URL Inspection results are the source, and a chat can help you read them.

If you want ongoing monitoring and post-change checks done for you, our [website maintenance](https://webleveling.com/services/website-maintenance/) service covers that, and our [SEO services](https://webleveling.com/services/search-engine-optimization/) cover the wider work of getting the site found. Before you spend anything, run the checks above; they are free and take an evening. If you want the broader sweep, our [afternoon website check](https://webleveling.com/blog/website-check-you-can-do-in-an-afternoon/) fits alongside it.

**Quiz: Can you spot a silent SEO breakage?**

1. Your site looks normal in your browser after an update. What does that prove about Google?
   - Google can index every page
   - Nothing; a page can look fine and still carry a noindex instruction **(correct answer)**
   - Your traffic will return within a day
   - Your robots.txt file is correct
2. A page is blocked in robots.txt. Is it guaranteed to stay out of Google?
   - Yes, robots.txt removes pages from Google
   - No, a blocked page can still appear if other pages link to it **(correct answer)**
   - Yes, but only on mobile
   - It depends on your hosting plan
3. You fixed a wrong noindex on your main service page. What comes next?
   - Do the live test, request indexing, and allow at least a week **(correct answer)**
   - Request indexing every hour
   - Delete the page and rebuild it
   - Change your domain name

## Frequently Asked Questions About technical seo issues hurting my website

**What are technical SEO issues?**

They are problems with how a site is built or set up that make it harder for Google to crawl, index or load your pages. Examples include a noindex instruction left on, a robots.txt block, a wrong canonical tag, broken redirects, password protection and server errors. Our post on [what technical SEO is](https://webleveling.com/blog/what-is-technical-seo/) goes deeper.

**Can a website update remove pages from Google?**

Yes. An update can add a noindex instruction, a robots.txt block, a wrong canonical tag, redirects that fail, access restrictions or server errors. Check the Page indexing report and URL Inspection right after any update.

**Does robots.txt remove a page from Google?**

No. It controls crawling. A blocked page can still be listed if Google finds it through other pages. To keep a page out, use noindex and let Google crawl the page so it can see the instruction.

**How can I fix SEO problems on my website?**

Find the cause in Search Console, change the setting in your platform, plugin or server, then run the live test in URL Inspection and request indexing for the pages that matter. Resubmit the sitemap if many pages changed.

**What kinds of website errors are there?**

Group them into pages that are blocked from Google, pages that are missing or redirected wrongly, and pages that return errors or load slowly. Each group has a different fix, so sorting them first keeps the repair short.

**Will Search Console email me about every SEO breakage?**

No. It emails you about important events, so use the email setting together with a monthly Page indexing check and a check after every site change.

## Moving Forward

Technical SEO issues from a site edit are quiet because your own browser hides them. The reliable answer is a routine: inspect your homepage and key pages after every change, read Page indexing once a month, keep Search Console email notifications on, and know the five usual causes so a pattern in the report makes sense when you see it. When you do find something, fix the cause, run the live test, request indexing for the pages that matter and give Google at least a week.

Handled this way, a bad update becomes a short repair job instead of a month of lost leads. You also get a dated record of what changed, which makes the next update less stressful.

If you would like someone to run these checks after every update, [Web Leveling](https://webleveling.com/) can do that, and our [website maintenance](https://webleveling.com/services/website-maintenance/) service is built for it. We work with small and medium businesses across the country and overseas, and you can [contact us about monitoring your site after changes](https://webleveling.com/contact/) whenever you are ready.

## Terms

Words used in this post

Tap a term to see what it means.

**Noindex.** An instruction that tells Google not to show a page in search results.

**Robots.txt.** A file at the root of a site that tells crawlers which areas to stay out of.

**Canonical tag.** A tag naming the preferred address when several addresses show the same content.

**Redirect.** An instruction that sends a visitor or crawler from an old address to a new one.

**Page indexing report.** A Search Console report that shows which pages Google has indexed and why others are not.

**URL Inspection.** A Search Console tool that shows how Google sees one page and lets you test the live address.

**Sitemap.** A file that lists the pages you want Google to know about.

- [Rank report shows a drop? Check Search Console first](https://webleveling.com/blog/rank-tracker-numbers-look-wrong/): Keywords missing from your weekly rank report? See what tracker vendors reported on dates from September 24, how to check your own data, and what to ask.
- [Search Console Performance Report Delayed: What to Check First](https://webleveling.com/blog/search-console-performance-report-delayed/): Search Console Performance report days behind? Check Google organic sessions and leads in Analytics first, and leave your site alone while Google catches up.
- [Does My Website Need a Sitemap? What to Check First](https://webleveling.com/blog/does-your-website-need-a-sitemap-and-robots-txt/): Google says a sitemap helps most on large, new, or media-rich sites. Check yours and robots.txt, then submit a sitemap in Search Console if you have one.