Technical SEO services for San Diego business websites.

A page Google can't reach or read counts for nothing, whatever is written on it. I find what blocks search engines and AI crawlers on your site, and I measure the effect of each fix.

No long contracts. You talk to Simon.

Map pack: roof repair san diego

Simplified map of San Diego County A B C
Illustrative
  • 17 years in SEO
  • Engineering degrees
  • 85% of clients in San Diego County
  • No long contracts

Where websites lose rankings quietly

  • A redesign went live and the calls dropped
  • Important pages are missing from Google's index
  • Pages load slowly on a phone over mobile data

How I do technical SEO

Scientific SEO

  1. 1 Measure You get a crawl, an index check and a speed test recording the site as it is.
  2. 2 Change one thing I put one fix live, such as a redirect map or a template change.
  3. 3 Measure again I check indexing and speed for the affected pages first, then rankings about two weeks later.
  4. 4 Keep what works I keep the fixes that showed an effect, and I document and reverse the rest.

What technical SEO fixes, and in what order

Technical SEO means finding and fixing whatever stops a search engine from reaching, loading, reading and storing your pages, because a page can rank only after all four have happened. The gain is that the content you already have gets counted, though none of the work adds anything a visitor would notice as new content.

How Google gets from your server to a ranking

Google finds a URL, fetches it, renders it and stores it in its index, in that order. A problem at any step ends the process. A page blocked in the robots.txt file (a list of instructions for crawlers) isn’t fetched. A page carrying a stray noindex tag, an instruction telling search engines to leave it out, is fetched and then dropped.

A page that only shows its text after JavaScript runs may be indexed late or incompletely, and several of the crawlers used by AI assistants don’t run JavaScript at all. Tracing a page through each step to find where it stops is indexing and crawling work.

Speed, measured the way Google measures it

Google judges speed from real visits made in the Chrome browser. It looks at how quickly the main content appears, how quickly the page responds to a tap and how much the layout shifts while loading. A lab score from a desktop on office wifi says little about a homeowner in Ramona on a phone with a weak signal.

On home-service sites, site speed and page experience problems usually come from oversized photos and a heavy theme, with third-party scripts such as chat widgets and trackers adding to the load. Once the site is fast enough I stop, because Google treats speed as one signal among many and past a certain point the time is better spent elsewhere.

Schema markup, and what it doesn’t do

A page can state facts in a format machines read directly: this is a local business, this is its phone number, these are its hours, these are the areas it serves. That code is schema markup, and it reduces guessing. It can also make a page eligible for some enhanced listings in Google, though eligibility is all it gives, and Google decides whether to show them. It doesn’t lift a page’s position by being present, and marking up things that aren’t on the page breaks Google’s rules.

I write schema markup using the types that matter for a service company. The same structured facts are also the raw material for entity and schema work aimed at AI assistants, since they bear on what an assistant says about a business.

Why the phone version is the one that counts

Google indexes the mobile version of a site, so whatever is missing or broken on a phone is missing as far as Google is concerned. That includes text removed from the page to save space on small screens and menus that never expose the inner pages. Phone numbers that can’t be tapped belong on the same list. A homeowner with water on the floor is likely to be searching on a phone, so these problems cost calls as well as rankings. I check mobile usability on real devices.

Migrations and redesigns

A migration is any change to a site’s domain, platform, design or URL structure, and it’s when rankings are most often lost by accident. The cause is usually old URLs that no longer redirect to their new equivalents, or a noindex tag carried over from the staging site. Content dropped because it didn’t fit the new template does the same damage.

Each is preventable in a planned site migration, with a redirect map and a checklist run before and after launch. If your site has already been relaunched and the calls fell, the same checks work in reverse, though recovery is slower than prevention and isn’t always complete.

How technical fixes are ordered and tested

I rank each problem by how many important pages it affects and how badly, then fix them one at a time. A problem that keeps your service pages out of the index goes ahead of a slow blog archive. After each fix I check the direct effect first (is the page now indexed, is it now fast) and the ranking effect about two weeks later. Some fixes show no ranking change, and I report that too.

If you want the whole site examined before any work starts, a technical SEO audit does that.

For a typical service site, technical work is a finite job. Once the problems are fixed, the effort moves to the pages themselves, which is organic SEO.

What a result looks like

Every engagement starts and ends with the same measurement.

Sample layout. Not a real client.

Trade, city: the problem in one line

Starting point
Rank grid before any change
What changed
The one or two changes that moved it
Result
Rank grid after, and the change in calls

Technical SEO across San Diego County

My new website launched and my rankings dropped. Can that be fixed?

Often it can, if I find the cause quickly. The usual culprits are missing redirects from the old URLs, a leftover noindex tag carried over from the staging site, or content that was cut in the redesign because it didn't fit the new template. I compare the old site's pages with the new one and close the gaps. Recovery isn't always complete, and the longer the problems stay live, the harder it tends to be.

Does my site speed score need to be 100?

No. A perfect lab score isn't a ranking requirement, and chasing it can cost more than it returns. I stop when the site is fast enough.

Will adding schema markup improve my rankings?

Any effect on rankings is indirect. Schema helps Google and other systems read your business facts without guessing, and it can make a page eligible for enhanced listings, which Google may or may not show. Being there doesn't raise a page's position. I add it because clear facts reduce errors, and I test any ranking effect the same way I test everything else.

Can you work with my existing website and developer?

Yes, and many technical fixes don't need a rebuild. I write each fix up as a specific instruction with the reason and the expected result, and either make the change myself or hand it to your developer, whichever you prefer. If the platform itself is the obstacle, I explain what moving would involve before you decide.

Find out what is holding your website back.

Your website address is enough for me to check how Google reaches, reads and indexes it.

  • A rank grid showing where you appear, and where you don't
  • The technical and Google Business Profile issues that matter most
  • What I'd change first, in plain English

Prefer to talk? Call (619) 675-7678, 9am to 6pm.

Step 1 of 2: your business

Your business

Where to reach you

No long contracts. You talk to Simon.

Call Get My SEO Audit