Technical SEO
& performance audit
in Torrance

Redirect chains are not designed. They accumulate. A migration adds one rule, a redesign adds another, a campaign adds a third, and four years later a single click passes through five hops before it lands.

Every hop costs something. Time for the visitor, a little value for the target page, and a place for a mistake to hide. A chain that ends in an error page is indistinguishable from a working link until somebody follows it.

So the first job is to see the whole set. Rules live in several places: the server configuration, a plugin, the application itself, sometimes the hosting panel. Reading one of those and calling it the inventory is how the count comes out wrong.

Once the set is visible, flatten it. Every rule points at the final destination rather than at another rule. That is mechanical work and it is the largest single improvement available here.

Loops are the other failure. Two rules pointing at each other produce a page that never loads, and browsers report it with an error nobody connects to redirects.

Then the question of what kind. A permanent redirect says the address has moved for good and passes value along. A temporary one says come back later. Using a temporary rule for a permanent move keeps the old address alive in the index indefinitely.

Not everything deserves a redirect. A page with no equivalent should say it is gone rather than dump the visitor on a home page, which helps nobody and tells a crawler nothing.

Watch what happens to parameters, because it is where rules usually lose something. A rule that drops the tracking parameters from an advertising link breaks the measurement rather than the page.

We check the whole chain after any migration by crawling the old address list and reading the number of hops, not the final status. A single check of the last code reports success on a chain five deep.

Technical SEO for a Torrance site starts at ~$600 when the audit comes with fixes and reaches ~$1,500 for a full setup. Small sites finish in four to eight weeks, per the timeline on this page. One recurring job inside that work is making every page agree on its own address.

A canonical tag is a request. Google weighs it against other signals, then picks the version it believes. When the signals disagree, it picks on its own. The pick can be the wrong URL.

The signals are few and concrete. The rel=canonical link. Redirects. The URL that internal links point at. The URL the sitemap lists. HTTPS over HTTP. A clean address over one with parameters. Each one is a vote.

Most conflicts come from templates. Say the canonical names /shoes/, the menu links to /shoes, and the sitemap lists /shoes/?ref=nav. Three votes, three answers. Google settles it and reports "Duplicate, Google chose different canonical than user" in Search Console.

Fix the votes before the tag. Internal links should use the canonical form exactly, down to protocol, host, trailing slash and letter case. The sitemap should list only canonical URLs that return 200. Once those line up, the tag confirms what the rest of the site already says.

Some patterns break canonicals outright. A canonical pointing at a page that redirects or returns 404. Two canonical tags in one document, one from the theme and one from a plugin. A tag written by script after load that differs from the one in the source. Google discards conflicting hints and falls back to its own choice.

Copies on other domains need the same care. A syndicated article or a product feed on a partner site can outrank the source. A cross-domain canonical on the copy is the cleanest request. It works only if the partner adds it.

Tracking parameters create duplicates by the thousand. A campaign link with utm tags gets shared, crawled and treated as a separate URL. The canonical on that page should name the clean address. Internal links should never carry utm tags at all.

Do not mix noindex with a canonical to another page. One says drop this URL, the other says merge it elsewhere. Pick one per template.

Files need canonicals too. A PDF duplicating an HTML page can take a Link header with rel=canonical pointing at the page. The same header works for any file type where a tag cannot sit in the document.

Host and protocol come first. HTTP and HTTPS, www and bare domain should resolve to one version through site-wide redirects. The sitemap and hreflang annotations then use that version only.

The check is URL Inspection. It shows the user-declared canonical and the Google-selected one side by side. We run it on a sample per template and list every page where the two differ, with the vote that caused it.