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
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
A
B
C
Scientific SEO
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.
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.
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.
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.
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.
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.
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.
Every engagement starts and ends with the same measurement.
Sample layout. Not a real client.
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.
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.
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.
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.
Your website address is enough for me to check how Google reaches, reads and indexes it.
Prefer to talk? Call (619) 675-7678, 9am to 6pm.