Find and Fix Technical SEO Problems

Maple Street CPA has spent time making better decisions about its website. The firm has written a clearer homepage draft, prepared a monthly accounting and advisory service-page draft, and planned how related pages might connect. Its accountants have also started reviewing the 15 tax articles already on the website.

None of the proposed new pages has been published. The live homepage still uses the broad heading Reliable Accounting and Tax Solutions.

Now the practice manager has another question: “When we improve our website, how do we know Google can find the pages?”

That's where technical SEO comes in. It is the work of checking whether a website functions properly for visitors and whether search engines can reach and understand its important pages.

You don't need to become a programmer to make good decisions about technical SEO. You do need to know which problem you're looking at, what evidence would confirm it and who can make a safe fix. If someone helps your firm with SEO, they should investigate the website and its reports themselves. You should not have to supply a technical audit to get started.

Imagine three different questions about the same article:

1. Is it published? Can a visitor open the real page on the website without signing in?
2. Can Google access it? Can Google’s crawler reach and read the page?
3. Has Google indexed it? Has Google decided to store the page in its search index?

A page may be published but not indexed. A page may be accessible to visitors but carry a noindex instruction that asks search engines not to include it. Google may also find two similar addresses and choose one as the main version.

Being indexed is not the same as ranking well. It means the page is eligible to appear, not that it will show for a particular search or bring clients.

The two improved Maple Street pages are still drafts. They are not ready for live URL checks or new public links. The right starting points are pages that are actually published, such as the current homepage and one of the existing tax articles.

The practice manager writes down the current homepage and Getting Your Records Ready for Tax Time, the published article the team began reviewing in Lesson 9. She does not assume there is a problem simply because the article has a short introduction.

To investigate Google indexing, the firm needs access to its verified website property in Google Search Console. The person doing the SEO work can use the URL Inspection tool to inspect the exact published address. If they don't have access, they should arrange access with the website owner rather than guess what Google sees.

The URL Inspection tool first shows Google’s recorded indexing information, including details from its last crawl. This may describe an older version of the page. Test live URL checks the current page for many access and indexing conditions. The two results can differ after a website change.

Explore the checks Maple Street can make. The firm has not yet recorded results for these pages, so these are questions to investigate, not findings.

Here's an example you might encounter during an accounting website review.

Imagine a different accounting firm inspects a published, professionally reviewed tax article that it wants people to find. Search Console reports:

URL is not on Google
Reason: Excluded by ‘noindex’ tag

The page itself opens normally. A visitor can read it. But the page contains an instruction telling Google not to include it in search results.

A website can send that instruction in the page's code or in a response header. For example, the code may include:

<meta name="robots" content="noindex">

You don't need to write that code yourself. What matters is understanding the instruction. noindex means “do not include this page in search results.” It may be completely correct for a public thank-you page you want to keep out of search. Use sign-in or another access restriction for genuinely private content. On a public article you want people to find, an accidental noindex needs fixing.

Practice example: Try the two live test states and compare them with the recorded result.

How a specialist would handle it

First, check the page's purpose. Is the article approved for public search? Has an accountant checked its facts? Was noindex intentional? Don't remove a deliberate setting just because a report calls the page “not indexed”.

Next, confirm the cause on the live page. Inspect the exact URL, review the indexing reason and run Test live URL. Check the site's search-visibility setting, the page's SEO settings and, if needed, its code or response headers. A website developer may help with the technical part.

Then, make the smallest appropriate fix. If the article should appear in search and the noindex instruction was accidental, remove it from that page. Don't switch off unrelated protections across the website. Make sure Google isn't also blocked from crawling the page.

Finally, verify what actually changed. Open the page again and run the live test. If it now says indexing is allowed, you've confirmed that particular restriction is gone. You can request indexing for the page, but Google still decides when to crawl it and whether to index it. Come back later to inspect the indexed status again.

The sequence is simple: confirm the purpose → find the cause → fix the cause → test again → follow up.

Try the decision for this example.

Some technical problems affect whether a page can appear in search. Others mainly make the website frustrating for a potential client. And some reports describe normal website behaviour rather than a problem.

Here are a few common situations:

• A broken link: A menu or article link takes a visitor to a page that no longer exists. Check whether the link should point to a moved page, and update it. If a page moved permanently, a redirect to its genuine replacement may be appropriate.
• A missing page: A page has intentionally been removed, and there's no suitable replacement. A 404 response can be correct. Redirecting every missing page to the homepage is not a good default.
• A blocked page: A robots.txt rule can prevent Google from crawling a page. A noindex instruction prevents indexing when Google can access and read it. Google can sometimes find a blocked URL through links elsewhere. If crawling is blocked, Google cannot read a noindex instruction on that page.
• A duplicate address: Google may choose one address as the main version of similar content. That can be expected, such as when a printable version points to the original. Check the chosen page before changing anything.
• A poor mobile experience: A contact button that doesn't work on a phone is important even if the page has no indexing warning. Test the actual visitor journey, not just a speed score.

A sitemap can help Google discover important pages, but it is not a promise that every listed page will be indexed. And a perfect performance score isn't a substitute for a working site that answers client questions.

Try choosing the safest response to each situation.

Imagine the noindex instruction has been removed from the practice example. The live inspection now says Google is allowed to index the page.

That's an important check, but it is not yet proof that Google has indexed the page. The next indexed result may still reflect an older crawl. The website owner can monitor it and ask for another crawl when appropriate. Even after indexing, the article may or may not appear for a particular search.

This is why a useful technical note records two separate things: what we verified on the live website, and what Google has later confirmed in its index.

To be eligible as a supporting link in Google’s AI Overviews and AI Mode, a page must be indexed and eligible to appear in Google Search with a snippet. That makes basic access, indexing and clear content relevant to AI visibility too.

It doesn't mean a technical fix automatically produces an AI recommendation. And it doesn't prove how ChatGPT or other AI services use that page, because those products have their own systems.

For your accounting firm, the best first step is still to make important published information accurate, accessible and useful, then measure the results rather than promise them.

Return to the real service and client type you chose earlier. Pick one page that matters to that goal. It might be your homepage, a published tax page, a bookkeeping service page or another page that actually exists.

If you have a website but haven't checked which page is live, record that as your first task. If you don't yet have Search Console access, note that you need permission to inspect the site. If your chosen service page is still a draft, check a published page first and keep the draft on your publication checklist.

Write down what you've seen, what you still need to verify, the first sensible action and how you'll check whether it worked. If you have not checked something yet, write “Not checked”.

Maple Street now has a sensible way to investigate its existing website before publishing the new homepage and advisory drafts. No technical fault has been confirmed yet. The team will start with its published homepage and the tax article it opened in Lesson 9.

You have a method you can apply to your own practice: choose an important live page, find out what the evidence actually says, take a careful action and check the result.