Welcome to the Q&A Forum

I'm doing on-page optimizations for an apartment management company, and they have about seven apartments listed on their site. Rather than include everything on the same page - /apartments/apartment-name/ - they have the following setup:

• /apartments/apartment-name/contact
• /apartments/apartment-name/features
• /apartments/apartment-name/availability
• /apartments/apartment-name/gallery
• /apartments/apartment-name/neighborhood

With very few exceptions, none of these pages appear to rank for anything, and those that do either rank very poorly for seemingly random keywords or for keywords like the apartment complex name (alongside the main landing page for the complex).

I'm of the mind to recommend combining the pages into a single one that contains all the info, eliminates the chances for duplicate content (all of the neighborhood pages contain the same content verbatim), and prevents keyword cannibalization.

Thoughts? Thanks.

All of our URLs in Google My Business are tagged with ?utm_source=gmb. This way when people click on it within a Google Map listing, knowledge graph, etc we know it came from there. I'm assuming using a canonical on all ?_utm_source _pages (we have others, including some in the index) won't cause any problems with this, correct? Since they're not technically traditional organic SERPs?

Dumb question I know, but better safe than sorry. Thanks.

Yeah, I'm trying to figure out the best way to present to them all the pertinent information regarding how terrible Shopify is. The way they use Collections then block any sort of parameters in their unalterable Robots.txt file is insane.

Hi all,

I have a client that has a unique search setup. So they have Region pages (/state/city). We want these indexed and are using self-referential canonicals.

They also have a search function that emulates the look of the Region pages. When you search for, say, Los Angeles, the URL changes to _/search/los+angeles  _and looks exactly like /ca/los-angeles.

These search URLs can also have parameters (/search/los+angeles?age=over-2&time[]=part-time), which we obviously don't want indexed.

Right now my concern is how best to ensure the /search pages don't get indexed and we don't get hit with duplicate content penalties. The options are this:

1. Self-referential canonicals for the Region pages, and disallow everything after the second slash in /search/ (so the main search page is indexed)

2. Self-referential canonicals for the Region pages, and write a rule that automatically canonicalizes all other search pages to /search.

Potential Concern: /search/ URLs are created even with misspellings.

Thanks!

Yeah, I know the difference between the two, I've just been in a situation where canonicals were recommended as a means of controlling the preferred page _within an indexation context. _If that makes sense.

My biggest concern is with the creation of URLs from misspellings, which still return search results if it's close enough. The redirects could work. Honestly that wasn't something we considered.

I'm liking the noindex approach. They'd have to write a rule that applies it to every page created with a search parameter, which I think they should be able to do.

If it helps, almost the entire site is run by Javascript. Like...everything.

Thanks for the advice. Much appreciated.

-Brad