1. Try to use Flash only where it is needed. Many rich media sites such as Google's YouTube use Flash for rich media but rely on HTML for content and navigation. You can too, by limiting Flash to on-page accents and rich media, not content and navigation. In addition to making your site Googlebot-friendly, this makes you site accessible to a larger audience, including, for example, blind people using screen readers, users of old or non-standard browsers, and those on limited low-bandwidth connections such as on a cell phone or PDA. As a bonus, your visitors can use bookmarks effectively, and can email links to your pages to their friends.
2. sIFR: Some websites use Flash to force the browser to display headers, pull quotes, or other textual elements in a font that the user may not have installed on their computer. A technique like sIFR still lets non-Flash readers read a page, since the content/navigation is actually in the HTML -- it's just displayed by an embedded Flash object.
3. Non-Flash Versions: A common way that we see Flash used is as a front page "splash screen" where the root URL of a website has a Flash intro that links to HTML content deeper into the site. In this case, make sure there is a regular HTML link on that front page to a non-Flash page where a user can navigate throughout your site without the need for Flash.
   

So I shouldn't be surprised when my friends tease me about my traveling as a representative of Google's Search Quality team: "Must be really rough!" However, being an active part of conferences actually isn't all glamour and relaxation.

Here's a glimpse of the reality:

• Sometimes (though thankfully rarely) I get metaphorically used as a human punching bag.
• There's no pause button on my corp and personal e-mail accounts. Days at conferences = LOTS of email to catch up on!
• And on a related note, what's with the no-wifi nonsense?! I have Verizon broadband [sic] for my laptop now, but still... ack!
  
• Attending conferences requires an enormous amount of extra time overall. I stubbornly seem to create presentations fresh for each conference, I collaborate with other Googler speakers on their presentations (and vice versa), and I end up with a ton of additional (valuable but time-intense) work from info I glean at the conferences. Based on this and the e-mail reason noted above, I've noticed that each day of conference = five days of combined prep + analysis + implementation.

But here's why I still really like going to conferences:

• I learn a bunch from other speakers. When folks from other search engines or various experts speak, I often think -- hey, that's useful information, or that's a particularly thoughtful way of explaining stuff. I'm still pretty new to the conference-speaking circuit, so every bit I soak up helps!
  
• SEO and webmaster folks are typically rather fun people. :-)
  
• Though I don't always make time for this, it's certainly neat getting to spend some time exploring various cities. Okay, so San Jose doesn't count (it's right next to Google), but I can't wait to check out Toronto (and, likely via a few personal days beforehand, Montreal).
• I learn a great deal from webmasters I chat with. I'm able to go back to my colleagues here and say - hey, this is how our algorithm changes or our guidelines are being perceived, these are challenges we didn't anticipate from our tools, and so on. And it's not just about search; I've gotten thoughtful earfuls about Gmail, Calendar, and practically everything else about Google, and I do my best to relay this feedback to my colleagues in other departments.
• Lastly, seeing someone in person provides a very helpful new perspective on what they're meaning to communicate online. It's easy to misread text on a page, especially when there's no immediate opportunity to follow up with questions. But in person, issues get cleared up on both sides, and that's good for everyone.

• Jianfei Zhu (Senior Software Engineer): Get a Lesson from Spamming

• Matt Cutts (Software Engineer): You&A, Personalized Search and Penalty Box
  
• Vanessa Fox (Product Manager, Webmaster Central): Duplicate Content

• For each page on domain X, have it 301-redirect to the corresponding page on Y. (How? Typically through .htaccess, but check with your hosting provider).
• You might want to stagger the move, and redirect sub-sections of your site over time. This gives you the chance to keep an eye on the effects, and also gives search engines' crawl/indexing pipelines time to cover the space of redirected URLs.
• http://www.google.com/webmasters is your friend. Keep an eye on it during the transition to make sure that the redirects are having the effect you want.
• Give it time. How quickly the transition is reflected in the results depends on how quickly we recrawl your site and see those redirects, which depends on a lot of factors including the current reputation of your site's pages.
• Don't forget to update your Sitemap. (You are using Sitemaps, aren't you?)
• If possible, don't substantially change the content of your pages at the same time you make the move. Otherwise, it will be difficult to tell if ranking changes are due to the change of content or incorrectly implemented redirects.

• Block appropriately: Rather than letting our algorithms determine the "best" version of a document, you may wish to help guide us to your preferred version. For instance, if you don't want us to index the printer versions of your site's articles, disallow those directories or make use of regular expressions in your robots.txt file.
• Use 301s: If you have restructured your site, use 301 redirects ("RedirectPermanent") in your .htaccess file to smartly redirect users, the Googlebot, and other spiders.
  
• Be consistent: Endeavor to keep your internal linking consistent; don't link to /page/ and /page and /page/index.htm.
• Use TLDs: To help us serve the most appropriate version of a document, use top level domains whenever possible to handle country-specific content. We're more likely to know that .de indicates Germany-focused content, for instance, than /de or de.example.com.
• Syndicate carefully: If you syndicate your content on other sites, make sure they include a link back to the original article on each syndicated article. Even with that, note that we'll always show the (unblocked) version we think is most appropriate for users in each given search, which may or may not be the version you'd prefer.
• Use the preferred domain feature of webmaster tools: If other sites link to yours using both the www and non-www version of your URLs, you can let us know which way you prefer your site to be indexed.
  
• Minimize boilerplate repetition: For instance, instead of including lengthy copyright text on the bottom of every page, include a very brief summary and then link to a page with more details.
• Avoid publishing stubs: Users don't like seeing "empty" pages, so avoid placeholders where possible. This means not publishing (or at least blocking) pages with zero reviews, no real estate listings, etc., so users (and bots) aren't subjected to a zillion instances of "Below you'll find a superb list of all the great rental opportunities in [insert cityname]..." with no actual listings.
• Understand your CMS: Make sure you're familiar with how content is displayed on your Web site, particularly if it includes a blog, a forum, or related system that often shows the same content in multiple formats.
• Don't worry be happy: Don't fret too much about sites that scrape (misappropriate and republish) your content. Though annoying, it's highly unlikely that such sites can negatively impact your site's presence in Google. If you do spot a case that's particularly frustrating, you are welcome to file a DMCA request to claim ownership of the content and have us deal with the rogue site.